конечно

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

выслал же

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

кстати 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)

docker webdav есть чо? синкать удаленные папочки в локальную

Какие знакомые все лица.

дык надо

коллеги, подскажите, плиз, в Docker Swarm разворачиваю сервис с одним инстансом контейнера, вешаю его на 80 порт. Потом, например, хост с докером, на котором был контейнер, падает и контейнер переезжает на другой хост. Как бы сделать так, что бы контейнер был всегда доступен по DNS независимо от того, на каком хосте он находится?

есть какие-то встроенные механизмы динамической регистрации в днс или что-то подобное?

consul

service discovery + monitoring + dns

и вот в добавок https://github.com/gliderlabs/registrator

Или @kubernetes_ru :)

благодарю

а вроде же в докер сворме свой днс встроенный

через него ни как нельзя это сделать?

про днс в сворме не знаю. Не пользовал ни разу

Даже не интересовался )

https://docs.docker.com/engine/swarm/ Service discovery: Swarm manager nodes assign each service in the swarm a unique DNS name and load balances running containers. You can query every container running in the swarm through a DNS server embedded in the swarm.

есть два сворма, старый, который отдельный, и новый, который как альтернативный режим докера, с верси 1.12

вот в новом вроде всё ок должно быть

ну вот про этот да, читал

без сторонних тулз

сам не юзал, хочу, но пока не когда

Мне пока даже негде.

оппа, вот про это не знал. попробую.

я когда только он релизнулся, тестил, в виртуалках, но что-то пошло не так и у меня между тремя виртуальными хостами сеть терялась, не мог mondodb replica set собрать

в 1.13 вот что реально хочется поюзать, так это: docker stack deploy --compose-file=docker-compose.yml my_stack т.е. появилась полноценная поддержка деплоя в swarm по compose конфигу

проверил - докер сварм через интерфейс docker_gwbridge отдает сервису единый внешний айпишник.

боюсь в swarm dns для внутренних целей и service discovery и если у тебя внешний DNS смотрит на IP ноды и она упадёт, то тут встроенные механизмы не помогут...

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

проверил - докер сварм через интерфейс docker_gwbridge отдает сервису единый внешний айпишник.

единый внутренний IP видимо ?

единый внутренний IP видимо ?

ну, это бридж сеть, с целью использования извне. но что-то пока не получается, что бы он отвечал что-то.

ну, это бридж сеть, с целью использования извне. но что-то пока не получается, что бы он отвечал что-то.

ну а как ты представляешь это? у разных нод свои IP, ты направил DNS внешний на любой из этих IP на 80 порт сервиса, Docker с помощью своей маршрутизации находит ноду где контейнер твой и маршрутизирует через overlay сеть на неё трафик

ну, это бридж сеть, с целью использования извне. но что-то пока не получается, что бы он отвечал что-то.

но когда эта нода упадёт, то DNS будет на тот же IP безрезультатно долбиться

ну, это бридж сеть, с целью использования извне. но что-то пока не получается, что бы он отвечал что-то.

тут надо или внешний балансировщик ставить, который будет точно доступен или ddns использовать

встроенный в docker dns сервис он для внутренних нужд вроде как, для того чтобы контейнеры могли друг с другом взаимодействовать, для service discovery

понял про DNS, спасибо. опробую вариант с балансировщиком

Парни, есть какой-то способ дизейблить сервисы в докер-композе?

Парни, есть какой-то способ дизейблить сервисы в докер-композе?

Из розетки выдерни

спс

Из розетки выдерни

скайпасс выдерни