гитлаб можно и локально поднять

можно взять кучу разного софта или гитлаб в котором уже все есть

и registry и ci

Угу, понял. Спасибо

https://docs.gitlab.com/ce/ci/docker/using_docker_build.html#use-docker-in-docker-executor

К вопросу о docker-in-docker

Прочитал да. Там следующий парагпаф про проброс сокета, помойму интереснее

Угу, можно и так. На счет логов рекомендую еще глянуть на ELK

Но объективно сравнить не могу, так как с greylog дело не имел

грейлог использует elastic как бэкэнд для индексации логов, так что в принципе можно спокойно юзать кибану рядом с эластиком. И даже логсташ если сильно хочется. Грейлог мне понравился тем что там есть алерты, потому что у меня все же основная задача не графики красивые рисовать, а получать инфу своевременно когда что-то упало или сыпит ошибками

грейлог использует elastic как бэкэнд для индексации логов, так что в принципе можно спокойно юзать кибану рядом с эластиком. И даже логсташ если сильно хочется. Грейлог мне понравился тем что там есть алерты, потому что у меня все же основная задача не графики красивые рисовать, а получать инфу своевременно когда что-то упало или сыпит ошибками

а Docker контейнер настраивается уже через драйвер syslog на хост где крутится greylog2 ?

грейлог использует elastic как бэкэнд для индексации логов, так что в принципе можно спокойно юзать кибану рядом с эластиком. И даже логсташ если сильно хочется. Грейлог мне понравился тем что там есть алерты, потому что у меня все же основная задача не графики красивые рисовать, а получать инфу своевременно когда что-то упало или сыпит ошибками

интересно, есть ли какие-то задержки внутри контейнера при такой работе... что если машина с greylog2 будет не доступна, не будут ли приложения в контейнерах подвисать и тормозить из-за этого ?

а Docker контейнер настраивается уже через драйвер syslog на хост где крутится greylog2 ?

не совсем понял вопроса. Грейлог это самостоятельный сервис, он может стоять где угодно, просто при запуске контейнера нужно указать чтобы он логировал через glef драйвер, и передать как опцию имя сервера где стоит грейлог. Т.е. это не глобальная настройка для докера, а индивидуальная для контейнера

интересно, есть ли какие-то задержки внутри контейнера при такой работе... что если машина с greylog2 будет не доступна, не будут ли приложения в контейнерах подвисать и тормозить из-за этого ?

если машина с грейлогом не доступна на момент запуска контейнера, контейнер не запустится

но если упадет когда контейнер уже работал, то просто в сислог хост машины демон начент срать ошибкой что сервер не доступен

не совсем понял вопроса. Грейлог это самостоятельный сервис, он может стоять где угодно, просто при запуске контейнера нужно указать чтобы он логировал через glef драйвер, и передать как опцию имя сервера где стоит грейлог. Т.е. это не глобальная настройка для докера, а индивидуальная для контейнера

а всё, увидел gelf не заметил параметр... просто интересно, поведение сервиса, если не доступна машина с greylog

я думаю этим же занимается сам Docker и на производительности самого приложения в контейнере никак не отражается ?

это я к тому, что служба при каждой записи в лог, не должна ждать по 30 секунд таймаута, из-за того сервер логов не доступен к примеру

нет конечно, демон делает это асинхронно

вот, это хорошо, спасибо

сам контейнер просто пишет в буфер stdout

да да

а дальше уже сам Docker решает каким драйвером обрабатывать

как ты настроил так и будет

я точню не помню, но помоему там можно даже настроить какими порциями выгружать логи

это удобнее, чем монтировать VOLUME, потом поднимать второй контейнер с filebeat, к нему подключать его и грузить в logstash... сразу 2 лишних звена выпадает из цепи

Даа, красота! И что самое крутое, можно вообще все логи перенаправить в stdout, включая те, к-ыене умеют туда выводиться: RUN ln -sf /dev/stdout /var/log/nginx/access.log RUN ln -sf /dev/stderr /var/log/nginx/error.log (из официального образа nginx)

ого, фигасе.

кто нибудь знает как можно передать docker container id между stage в .gitlab-ci.yml ?

кто нибудь знает как можно передать docker container id между stage в .gitlab-ci.yml ?

не юзал, но можно же задавть контейнеру известное имя добавив ему для уникальности номер билда к примеру или хэш комита

А если через сварм запустить контейнер на другом серваке то как ему том подрубать через -v?

откуда?

Чего откуда

Как папку смонтировать-то?

А зачем?

В вольюмах храни

А волюм по сети как?

А волюм по сети как?

зипом и раздавать из Артифактори

Жизненный вопрос

Есть контейнер, из него обращаеются к ссылке

DNS на хостовой машине

Я пошел гуглить конечно, но может кто знает

Так что насчет тома?

Как по сети примонтировать

Вероятно надо пошукать на тему кастомных драйверов томов. Логи и сеть точно можно а вот томА - не уверен. Быть может проще будет примонтировать по nfs а потом уже как обычно

Как по сети примонтировать

примонтируй по сети на хост машины, а там уже просто монтируй как локальную папку. Я не знаю, может что-то изменилось, но раньше директива монтирования работала точно также в кластере, монтировать не рекомендуют, потому что то что монтируешь должно быть доступно на каждой из машин кластера, т.к. докер будет искать файлы локально, но как я сказал до этого, монтируешь то что надо на все тачки кластера, а потом со спокойной душой говоришь примотировать эту папку в конейнер указывая уже локальный путь, который будет на всех хост машинах одинаковый

но это костыль, почему не добавить нужное файло тупо в билд образа?

сейчас даже конфиги где могут содержаться пароли, ssl серты и т.д. рекомендуют хранить в docker secret, он доступен на любом хосте будет...

можно и просто конфиги там хранить, чтобы в сам образ не пихать

что за docker secret, прямо как js фреймворки как будто, каждый день новая приблуда

что за docker secret, прямо как js фреймворки как будто, каждый день новая приблуда

https://docs.docker.com/engine/reference/commandline/secret/

https://docs.docker.com/engine/reference/commandline/secret/

а есть "пост в поддержку" ?

https://blog.nimbleci.com/2016/11/17/whats-coming-in-docker-1-13/#secrets-management

конечно

будьте так любезны?

выслал же

будет не лень на выходных запилю на русском

кстати https://docs.docker.com/engine/swarm/secrets/

чорт, почему-то сразу не показалось )

спасибо!

как в хабре поставить перевод?

кто нить знает ?

@agick там у тебя в заголовке поста "Хочу разместить публикацию" - вот "публикацию" это на самом деле список

нажмёшь на неё и будет выбор "перевод"

@agick там у тебя в заголовке поста "Хочу разместить публикацию" - вот "публикацию" это на самом деле список

ну поток и зхаб выбрал не могу найти метку указать перевод

ты не понял

нужен кому перевод? ссылки выше?

https://www.dropbox.com/s/lllxzls5pok75q5/%D0%A1%D0%BA%D1%80%D0%B8%D0%BD%D1%88%D0%BE%D1%82%202017-01-31%2012.10.17.png?dl=1

https://www.dropbox.com/s/lllxzls5pok75q5/%D0%A1%D0%BA%D1%80%D0%B8%D0%BD%D1%88%D0%BE%D1%82%202017-01-31%2012.10.17.png?dl=1

понял

выслал же

судя по cat /run это всё 1 - удобная обёртка над стандартным -v 2 - все секреты висят в оперативке так?

Secrets are encrypted during transit and at rest in a Docker swarm.

прочитай

When you add a secret to the swarm, Docker sends the secret to the swarm manager over a mutual TLS connection. The secret is stored in the Raft log, which is encrypted. The entire Raft log is replicated across the other managers, ensuring the same high availability guarantees for secrets as for the rest of the swarm management data.

The secret is stored in the Raft log, which is encrypted.

звучит неплохо

не так

Warning: Raft data is encrypted in Docker 1.13 and higher. If any of your Swarm managers run an earlier version, and one of those managers becomes the manager of the swarm, the secrets will be stored unencrypted in that node’s Raft logs. Before adding any secrets, update all of your manager nodes to Docker 1.13 to prevent secrets from being written to plain-text Raft logs.

есть такая пометка

я в принципе могу перевести эту статью чуть позже и запилить на хабру

либо собрать вопросы и туториал сделать, ибо пришлось покопаться в secret

Один вариант пробросить папку с другого сервера это примонтировать ее через nfs. А вариант с glusterfs что думаете?

А как вы живете с docker+iptables-pesistent?

есть некий образ(на alpine 3.4, если важно), который я запускаю с монтированием текущей папки docker run --rm -ti -v $(pwd):/usr/src -w /usr/src somestuff sh какой существует актуальный способ добиться того, чтобы небыло конфликтов с правами? нормальным ли считается решение с entrypoint в образе, в котором создается пользователь с таким же uid, как и на хосте и из под него всё работает внутри контейнера? если нет, ткните, плз, куда гуглить

uid текущего пользователя на разных машинах может отличатся, наступал на эти грабли

самое просто при запуске контейнера проставить права, ты же там внутри от рута, он позволит тебе

если контейнеров несколько, то имеет смысл создать юзера с одинаковым uid

чтобы если один контейнер чего то создает, другие теже права имели

моя боль в том, что мне нужна возможность на хосте править файлы, которые монтируются в контейнер. спрашиваю в надежде на то, что в последних релизах есть нечто, что поможет избежать костылей

для прода лучше отдельный пользователь для всего зоопарка, наверное

а я через группу сего добиваюсь

добавил себя в www-data

ну вариант иметь группу конкретным айди на хост машине и в контейнерах

ну да, можно и специализированную создать. так даже кошерней

Минутка извращений. У кого-нибудь был опыт отладки scrapy из docker в vs code? (Win10)