Но, есть же и локальный запуск, на компе дева.
Но, в общем я полностью согласен. Но, это бы удлинило статью. И немного, выходит за область рассматриваемой теме.
Тут, дело не столько в микросервисах, подобный кейс бывает и при монолите.
Тут, надо учесть 2 момента:
1. Автоматическое переподключение приложения к БД.
2. Helth check который отдает данные по работе приложения, в частности с учетом доступности/недоступности БД. И вешать его на мониторинг.
Спасибо за развернутый комментарий.
Да, я уже понял, что надо еще одну статью писать. В ближайшее время напишу и опубликую. К этой статье добавлю ссылку.
Если вы еще не твердо
В жизни выбрали дорогу,
И не знаете, с чего бы
Трудовой свой путь начать,
Бейте лампочки в подъездах —
Люди скажут вам «Спасибо».
Вы поможете народу
Электричество беречь.
Я думаю что нет. Так же и со статьей, если ты не понял, почему так не надо делать. То, стоит почитать соответствующий раздел документации.
Иначе мы так и будет жить в мире копипаста.
> все-таки ожидал увидеть все это не среди комментариев, а в самой статье.
Цель этой статьи была другая. Тут, совсем не преследовалась цель показать, как надо делать и уж тем более, объяснить почему так не надо делать. Разобрать все кейсы, все ошибки невозможно. Я постарался показать, наиболее распространённые ошибки, а кому это нужно, может посмотреть документацию, комментарии и множество статей и тем самым хорошо разобраться с данным вопросом.
Если бы, статья содержала подробный разбор, это было бы не так полезно. ИМХО.
На мой взгляд, тут было варианта:
1. Пообщаться с ИИ, и попросить его помочь. Потом, предложить TeamLead уже готовое решение.
2. За пару выходных разобраться самому и предложить TeamLead готовое решение.
Вряд ли Lead настолько глуп, что откажется уже от готового решения. А если это и так, то продолжать потихоньку прокачивать свои знания и предлагать свои решения, более правильные. И как знать, может через полгода год, jinior станет Lead:)
Что не так? Последовательно:
1. Очистка кэшей и тд сделано отдельным RUN, это приводит к созданию еще одного слоя, где эти данные удалены. Но, предыдущих слоях они остаются. Что бы это было ок, надо чистить в том же RUN. Правильно:
В этом случае, в слое не будет лишних данных. Аналогично и с зависимостями ruby.
2. Для выполнения RUN gem install bundler весь код не нужен. Достаточно скопировать:
Gemfile и Gemfile.lock. Они редко меняются и в большинстве случаев слой будет браться из кэша.
3. ssh там не нужен
4. Supervicor там тоже не нужен, на выходе должно быть несколько контейнеров:
С бэком и passenger в качестве бэкэнда.
С демонами, по одному на каждый демон.
Идеалогия Docker один контейнер, один процесс.
5. Версии должны фиксироваться. Использовать тэг latest это плохо, так как каждый раз мы можем получить совершенно разные контейнеры с разным поведением.
6. Желательно использовать не root в контейнере. По этому поводу, даже была недавно статья на хабр.
7. Использовать большие образы, это плохая практика. Так как, чем больше базовый образ, тем больше в нем багов.
Но, в общем я полностью согласен. Но, это бы удлинило статью. И немного, выходит за область рассматриваемой теме.
Тут, надо учесть 2 момента:
1. Автоматическое переподключение приложения к БД.
2. Helth check который отдает данные по работе приложения, в частности с учетом доступности/недоступности БД. И вешать его на мониторинг.
Например тут: https://m.habr.com/ru/company/acribia/blog/448704/
Да, я уже понял, что надо еще одну статью писать. В ближайшее время напишу и опубликую. К этой статье добавлю ссылку.
Если вы еще не твердо
В жизни выбрали дорогу,
И не знаете, с чего бы
Трудовой свой путь начать,
Бейте лампочки в подъездах —
Люди скажут вам «Спасибо».
Вы поможете народу
Электричество беречь.
Я думаю что нет. Так же и со статьей, если ты не понял, почему так не надо делать. То, стоит почитать соответствующий раздел документации.
Иначе мы так и будет жить в мире копипаста.
Цель этой статьи была другая. Тут, совсем не преследовалась цель показать, как надо делать и уж тем более, объяснить почему так не надо делать. Разобрать все кейсы, все ошибки невозможно. Я постарался показать, наиболее распространённые ошибки, а кому это нужно, может посмотреть документацию, комментарии и множество статей и тем самым хорошо разобраться с данным вопросом.
Если бы, статья содержала подробный разбор, это было бы не так полезно. ИМХО.
Весь Dockerfile показывает, как делать не надо. На то, они и вредные советы;)
1. Пообщаться с ИИ, и попросить его помочь. Потом, предложить TeamLead уже готовое решение.
2. За пару выходных разобраться самому и предложить TeamLead готовое решение.
Вряд ли Lead настолько глуп, что откажется уже от готового решения. А если это и так, то продолжать потихоньку прокачивать свои знания и предлагать свои решения, более правильные. И как знать, может через полгода год, jinior станет Lead:)
1. Очистка кэшей и тд сделано отдельным RUN, это приводит к созданию еще одного слоя, где эти данные удалены. Но, предыдущих слоях они остаются. Что бы это было ок, надо чистить в том же RUN. Правильно:
RUN apt-get -y install libpq-dev imagemagick gsfonts ruby-full ssh supervisor && \apt-get clean && \
rm -rf /var/lib/apt/lists/* /tmp/* /var/tmp/*
В этом случае, в слое не будет лишних данных. Аналогично и с зависимостями ruby.
2. Для выполнения RUN gem install bundler весь код не нужен. Достаточно скопировать:
Gemfile и Gemfile.lock. Они редко меняются и в большинстве случаев слой будет браться из кэша.
3. ssh там не нужен
4. Supervicor там тоже не нужен, на выходе должно быть несколько контейнеров:
С бэком и passenger в качестве бэкэнда.
С демонами, по одному на каждый демон.
Идеалогия Docker один контейнер, один процесс.
5. Версии должны фиксироваться. Использовать тэг latest это плохо, так как каждый раз мы можем получить совершенно разные контейнеры с разным поведением.
6. Желательно использовать не root в контейнере. По этому поводу, даже была недавно статья на хабр.
7. Использовать большие образы, это плохая практика. Так как, чем больше базовый образ, тем больше в нем багов.
Это из основного.
Да, еще можно еще много, чего добавить. Например, установку systemd.
Я, с удовольствием, в комментариях, поясню непонятные моменты.
Писать отдельную статью, не вижу смыла, их и так уже 100500.
Так же, советую, почитать: docs.docker.com/develop/develop-images/dockerfile_best-practices