Может у тебя там какой-то навороченный сервис конечно...

Делаю конфиги на puphpet, минут 5 точно подъем

Может у тебя там какой-то навороченный сервис конечно...

Обычный lamp

Делаю конфиги на puphpet, минут 5 точно подъем

У меня и на puppet было около минуты или меньше и сейчас на ansible. Дело ж не в инструменте а в том что ты поднимаешь там внутри

Делаю конфиги на puphpet, минут 5 точно подъем

Ну самый первый запуск да, 5-15 минут когда качает бокс, все разворачивает. Но потом же когда все готово это 40-60 сек.

Просто виртуалка запускается по сути.

Ну самый первый запуск да, 5-15 минут когда качает бокс, все разворачивает. Но потом же когда все готово это 40-60 сек.

А, так то да.. Я про первый.. просто докер не должен так долго работать

У меня lamp работал на 256 ОЗУ VPS :)

А, так то да.. Я про первый.. просто докер не должен так долго работать

А, ну блин, а ты часто убиваешь виртуалки что тебе это критично?

Ну и докер работает хоть год, норм :)

А, ну блин, а ты часто убиваешь виртуалки что тебе это критично?

Нет, просто я хочу совершенства :) думаю может я один жду столько

Нет, просто я хочу совершенства :) думаю может я один жду столько

Так докер все-равно будет качать образы и устанавливать пакеты когда будешь билдить. Да, быстрее но процентов на 20 может не больше имхо.

И потом когда сбилдишь он будет поднимать старый образ

кеш сборки, кеш образов. полтора часа сборки можно уменьшить до 40 секунд

Так же как и виртуалка, просто контейнер легче ж

кеш сборки, кеш образов. полтора часа сборки можно уменьшить до 40 секунд

Ну это то же самое что и с вагрантом, один раз билдишь минут 5, потом по 20-40 секунд запуск. Особой разницы не вижу.

Ну кроме легковесности контейнера :-/

Ну кроме легковесности контейнера :-/

Сделаю контейнер, проведу замер

Сделаю контейнер, проведу замер

ты только различай же время билда и время запуска из кеша :)

поясните плиз - запускаю docker-compose up -d конфиг из 2х простых контейнеров далее если я хочу примонтировать к одному из них volume с кодом

мне это делать как ту - http://blog.cloud66.com/how-to-get-code-into-a-docker-container/ - docker run -d -P --name <name of your container> -v /path/to/local/directory:/path/to/container/directory <image name> ?

или лучше сразу дописать в docker-compose.yml этот volume

Всем привет

или лучше сразу дописать в docker-compose.yml этот volume

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

Всем привет

Подскажите пожалуйста, как сделать два контейнера, один с nodejs допустим а второй awscli s3 с конфиг файлом. Как можно сделать так чтоб, когда я заливаю картинки на s3, он думал что он авторизирован, благодаря второму контейнеру aws s3. Достаточно ли их посадить в один network?

Подскажите пожалуйста, как сделать два контейнера, один с nodejs допустим а второй awscli s3 с конфиг файлом. Как можно сделать так чтоб, когда я заливаю картинки на s3, он думал что он авторизирован, благодаря второму контейнеру aws s3. Достаточно ли их посадить в один network?

ты хочешь ходить из одного контейнера через другой контейнер в с3, так?

это не очень хорошая идея, проксировать запросы к s3

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

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

ты написал другое

но может оно будет работать, если я их в один netowrk кину

я написал как я и сказал, что у меня два контейнера один с nodejs а второй с awscli s3 конфигом

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

я написал как я и сказал, что у меня два контейнера один с nodejs а второй с awscli s3 конфигом

"а второй awscli s3 с конфиг файлом" звучит как awscli c конфигом а не как awscli конфиг

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

тебе в сторону дата контейнеров смотреть надо тогда

ну так у меня и так все в контейнерах

и volumes_from

какой смысл использовать volumes_from?

я на оборот не хочу чтоб в контейнере лежали конфиг файлы

если его ломанут, то там ничего не будет

все конфиги будут подключаться из другого контейнера

лол

лучше бы сказал в чем ошибка

а не лол

навряд ли я пойму так свою ошибку

https://docs.docker.com/engine/tutorials/dockervolumes/#data-volumes

чувак, ну вот ты не хочешь доку читать

а тебе надо

читать? я уже все прочитал

сорри

плохо читал как то

Creating and mounting a data volume container

вот в дата вольюм контейнер и кладешь свои конфиги

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

ну и зачем мне это

чем это отличается от того что у меня в контейнере уже будет конфиг файл

чтобы у тебя конфиги были в контейнере

так же можно зайти и посмотреть что в файле

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

куда зайти что посмотреть?

с созданием своего конфига проблем нет

я именно не хочу чтоб сам конфиг файл, лежал в контейнере с приложением

а он через volume, все равно туда попадет, если брать твой способ

он и так и так туда попадет

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

я что-то подобное делаю с mysql

ERROR: S client not available

для awscli конфиг должен быть локально лежать.

когда делаю dump

понятно

я же не знаю можно ли так сделать или нет

ладно, тогда ничего не сделать

спасибо @beastea

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

спасибо @beastea

передавай весь конфиг в ENV вариэйблах) и надейся что ломающий не додумается их почитать )

передавай весь конфиг в ENV вариэйблах) и надейся что ломающий не додумается их почитать )

это кстати пятак. о таком я и не подумал

etcd

если его ломанут, то там ничего не будет

так это а вас часто ломают?

Вопрос передачи парольчиков в конетйнер очень больной. и просто он к сожалению не решается.

навряд ли через ENV я решу проблему, должен лежать же файл в папке. Я и так передаю ENV, но дальше он мне генерирует файл в папке .aws/config.json

а.

может и можно как-то в памяти хранить, не знаю.

навряд ли через ENV я решу проблему, должен лежать же файл в папке. Я и так передаю ENV, но дальше он мне генерирует файл в папке .aws/config.json

а это не подойдет? https://docs.docker.com/engine/swarm/secrets/#simple-example-get-started-with-secrets

тоже не подойдёт, секреты будут в /run/secrets лежать, отличий от того что оно будет примонтировано немного. если поломают приложение с последующим доступом к фс контейнера, то это не спасёт.

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

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

Вопрос передачи парольчиков в конетйнер очень больной. и просто он к сожалению не решается.

секреты ж

Ну или предельно простой одноразовый NC на хосте который будет отдавать при первом запросе всё что в него передано и отключаться.

секреты ж

секреты - это прямой текст внутри контейнера, так?

Это файлы внутри контейнера, но в общем то да

Это файлы внутри контейнера, но в общем то да

тогда в чем сохранность?

Оно при деплое не светится.

А для сохранности можно хащикорповское чтонить использовать или просто nc

Оно при деплое не светится.

ну из nc ты все равно в файл будешь писать. а так единственный вариант более/менее - vault, да

Из nc можно получать значение уже из приложения, и сразу использовать

если мы с тобой про один nc говорим

netcat, да

секреты ж

ты про docker secret ?