Alf 🙀
автоматизированные тесты вроде не актуально больше
Alf 🙀
фб сказал что так только лохи делают
Alf 🙀
у нормальных пацанов все юзеры тестируют
Oleg
идея - упаковался nginx+fpm+код, запустился где-то там в сварме, отработал свое, уничтожился
Oleg
лол
Alf 🙀
не ну ок идея.
Alf 🙀
только непонятно при чем тут автоматизированные тесты
Alf 🙀
и что именно под этим вы понимаете
Alf 🙀
ну и это тесты пускайте во время билда контейнера а не после а то тдд прогнило уже давно сейчас бдд модно у автоматизаторов
Slava
это все собачье дерьмо. Настоящие пацаны алгебру выстаривают и тестируют законы
Vitalii
Вижу на данный момент оптимальным вариантом - упаковка nginx+fpm+код в один контейнер.
Я же эту тему месяц мусолил в чатике. Решено было что docker-way это каждый контейнер снабдить нужным кодом.
Vitalii
Если два контейнера с nginx и php-fpm то в каждом должен быть код приложения. Где-то полный, а где то только статика. Но никаких общих шардов с кодом не должно быть. Тому есть ряд причин: отказоустойчивость, обслуживание, масштабирование и прочее вытекающее.
Vitalii
Стройте контейнеры в CI (там же тесты) и доставляйте на продакшен автоматически.
Vitalii
И будет счастье:)
Evgeny
Помнишь я спрашивал про пыхеров и их любовь к странному? Ну так вот пока только они были в этом замечены
Sergei
Если два контейнера с nginx и php-fpm то в каждом должен быть код приложения. Где-то полный, а где то только статика. Но никаких общих шардов с кодом не должно быть. Тому есть ряд причин: отказоустойчивость, обслуживание, масштабирование и прочее вытекающее.
Почему бы не научиться генерить статику отдельно от приложения?
Всякая нарезка нарезка картинок это отдельное приложение, возможно с апи.
В нжинксе код приложения не нужен. Всякие скрипты и стили генерить тоже отдельно от приложения
Sergei
Так будет и докер вэй и масштабируемо
Vitalii
Почему бы не научиться генерить статику отдельно от приложения?
Всякая нарезка нарезка картинок это отдельное приложение, возможно с апи.
В нжинксе код приложения не нужен. Всякие скрипты и стили генерить тоже отдельно от приложения
сейчас так и делаю. Это самый правильный но и трудозатратный путь.
Vitalii
Коллеги, подскажите правильный путь деплоя имаджей на продакшен после релиза их через Gitlab CI? Какие есть варианты?
Vitalii
У меня был вариант через раннер запущенный на продакшене. Но тогда получается, что часть сценария .gitlab-ci.yml нужно выполнить в раннере с докером на дев сервере, а часть в совсем другом shell раннере на продакшене.
Vitalii
На продакшене все равно запущен докер-демон (сервер), который может получать команды. Может можно как-то его дернуть удаленно и попросить его подтянуть новые образы и запустить контейнеры? Слышал про Swarm и docker-machine... но вот сел читать про это. Подскажите куда читать более правильно :)
Maxim
https://docs.docker.com/engine/reference/api/docker_remote_api/
Vitalii
Я хоть в правильном направлении двигаюсь?
Vitalii
Почему бы не научиться генерить статику отдельно от приложения?
Всякая нарезка нарезка картинок это отдельное приложение, возможно с апи.
В нжинксе код приложения не нужен. Всякие скрипты и стили генерить тоже отдельно от приложения
кстати, а вот и не всегда подходит ваш вариант (когда nginx контейнеру не нужны файлы проекта). Например в корне рядом с index.php лежит robots.txt. Кто же будет его отдавать? ))
Pavel
robots.txt это статика
Vitalii
та же фавиконка тоже рядом часто лежит.
Vitalii
да, ее должен отдавать nginx но в то же время robots.txt это часть проекта (лежит в одном репо с кодом)
Pavel
это тоже статика
Vitalii
это понятно что статика. Выше звучало следующее "В нжинксе код приложения не нужен. Всякие скрипты и стили генерить тоже отдельно от приложения"
Vitalii
ну то есть часть файлов из репозитория с кодом все же должны попасть в контейнер с nginx
Pavel
То что это все лежит в одном репо - это просто так получилось. Можно разложить их в 2 репо.
Vitalii
ну, тоже верно :)
Ок, Павел, есть мысли по поводу деплоя на прод контейнеров после билда в CI?
Pavel
я гитлаб не настраивал
Vitalii
ну тут пока важная общая идея, как сбилденные контейнеры поместить на прод и перезапустить там все. Общий подход интересует. Делал?
Pavel
Общий подход таков: сбилденные контейнеры поместить на прод и перезапустить там все.
Pavel
Ну есть всякие swarm, kubernetes и т.д.
Vitalii
Общий подход таков: сбилденные контейнеры поместить на прод и перезапустить там все.
в том то и вопрос, какими средствами можно поместить контейнеры на прод и перезапустить там все?
Pavel
в докере это через репозиторий
Pavel
Построенный контейнер пушишь в докер-репозиторий (registry), а на продах его вытягиваешь
Vitalii
ок
Vitalii
какими средствами можно в автоматическом режиме (командой из ci) вытянуть имеджи на прод и перезапустить там все?
Vitalii
у меня уже есть сбилденные контейнеры. Я хочу сбвинуться дальше :) не знаю куда идти и что читать
Pavel
Это команды bash либо встроенные доменные языки CI систем
Pavel
Можно в крайнем случае без регистра даже, просто экспортировать контейнер в файл и копировать его на прод
Vitalii
нет, надо из регистри
Pavel
https://docs.docker.com/engine/reference/commandline/push/ вот это читал?
Vitalii
я понимаю что это баш и бла бла бла
Vitalii
конечно читал
Vitalii
я же говорю, после отрбаоты CI у меня в регистри появляются нужные образы контейнеров с кодом приложения и полным фаршем
Pavel
https://docs.docker.com/engine/reference/commandline/pull/ а вот это? :)
Vitalii
осталось только в тот же CI добавить волшебную логику которая волшебно идет на прод и просить докер на проде подтянуть новые образы и пересоздать нужные контейнеры
Vitalii
я сейчас это все руками делаю.
Pavel
Как перезапустить - слишком абстрактный вопрос. Перезапускай как тебе удобно. В примитивном случае просто стопаешь один контейнер и запускаешь другой.
Vitalii
Павел, ты реализовывал то, что хочу реализовать я?
Pavel
Нет.
Pavel
Потому что непонятно чего ты хочешь :)
Pavel
Я реализовывал только понятные вещи.
Vitalii
да что не понятного?
Есть CI сервер который выполняет комады - это понятно?
Vitalii
команды выполняются на машине А
Продавшен сервер назодиться на машине Б
Vitalii
вопрос - как с машины А попросить машину Б сделать то, что мне нужно?
Vitalii
при этом соблюдая безопасность и все остальные понятные всем дела
Pavel
Через ssh например?
Maxim
в gitlab ci можно же подключиться по ssh, и произвести уже манипуляции с docker демоном
Maxim
не?
A.
вопрос - как с машины А попросить машину Б сделать то, что мне нужно?
Жену посадить за вторую машину
Vitalii
вооот... ssh... я и спрашиваю как это можно сделать:) Так как я хз и вариантов нагуглить не удалось. Везде платные сервисы деплоя докеримеджей
Maxim
смотри, у тебя есть сиай, который идет по ssh на сервер, после этого делает docker pull $image && docker run $image
Vitalii
Жену посадить за вторую машину
Вот! Единственный пока что вариант человек предожил.
Еще есть? Что там с ssh? Как авторизация? где ключик\пароль хранить
Maxim
https://docs.gitlab.com/ee/ci/ssh_keys/README.html
Vitalii
во, вариант. Пока что единственный более или менее реальный и поддериваемый самим СИ. Ок
Pavel
Просто ssh это базовейшая вещь, никогда бы не подумал что такой ответ станет для тебя полезным
Vitalii
ssh - это руками
Vitalii
я сейчас так и делаю.
Vitalii
а о том что этот способ поддерживает СИ из коробки и ключики предусмотрены и тд и тп это уже знать надо
Pavel
Так ты просто прочитай всю документацию по Gitlab по диагонали, чтобы вообще поиметь представление о том что он умеет потенциально
Vitalii
ну тоже вариант, но вот проблемка в том что ее много :)
Я прочел базовые вещи которые попадались в интернетах и по ссылкам рекомендованым а до этого не дошел. А чтобы по ней искать надо хотя бы примерно понимать что искать.
Vitalii
так, а что если у меня куча серверов по которым раскиданы имаджи и коннектриться к каждому не варинат?
Есть механизмы управления кластерами ... типа из СИ кинул команду кластеру а он сам там на докеры каждому серверу стукнет и все перезапустит?
Pavel
Короче базово, тебе нужно на билд сервере создать .sh скрипт, в который напихать башевских команд подключения к продакшен серверам и перезапуска там контейнеров.
Pavel
И этот скрипт запускать по окончании билда контейнера