Compose на проде. На единственной машине без репликаций, без failover, бекап базы на мастере. Удачи.А дальше тотже docker-compose up
Думаю статью с репозиторием решения написать. Попробвали несколько вариантов вместе с devops-ом, нормальное решение - это Docker-in-Docker . https://hub.docker.com/_/dockerВот кстати что меня ещё в Докере беспокоит. Крон и подобные процессы непонятно как запускать правильно.
cron:
image: library/docker:stable
deploy:
replicas: 1
restart_policy:
condition: on-failure
volumes:
- /var/run/docker.sock:/var/run/docker.sock:r
- ./cron/crontab:/tmp/cron-root:r
- ./cron/files/scripts:/root/scripts:r
- ./cron/files/docker-entrypoint.sh:/docker-entrypoint.sh:r
environment:
DOMAINS: 'example.com *.example.com'
DOCKER_HOST: "unix:///var/run/docker.sock"
SHELL: /bin/sh
PATH: /usr/local/sbin:/usr/local/bin:/usr/sbin:/sbin:/usr/bin:/bin
CRON_TZ: UTC
DNS_PROPAGATION: 1800
DNS_API_KEY: /home/.apikey
entrypoint: ["/docker-entrypoint.sh"]
command: ["crond", "-f", "-l2", "-L", "/var/log/cron.log"]
healthcheck:
test: ps aux | grep '[c]rond' || exit 1
interval: 3s
timeout: 10s
retries: 3
docker run --privileged --rm \
--name certbot-get-certs \
--volumes-from ${main_router_id} \
-v "${API_KEY_FOLDER}:${API_KEY_FOLDER}" \
certbot/dns-linode certonly \
--dns-linode \
--dns-linode-propagation-seconds ${DNS_PROPAGATION} \
--dns-linode-credentials ${LINODE_API_KEY} \
--server https://acme-v02.api.letsencrypt.org/directory \
--email [email protected] \
--agree-tos \
${CERTBOT_DOMAIN_OPTION}
к сожалению, гомогенную среду, где все запускается через artisan schedule:run, найти все сложнее,С современными фреймворками, подразумевающими единственную запись в кроне вида * * * * * php artisan schedule:run, достаточно тупого шелл-скрипта.
Снаружи. Смотрю expiration сертификата, если явно уже должен был обновиться, но не обновился - значит, что-то не так.а как ты мониторишь
...и еще это все горизонтально отмасштабировать, да. Ну у меня получается пока гомогенно делать, крон-задача может просто дернуть другой сервис по http, скажем.чаще надо рассылки отправлять одним приложением, сертификаты продлять другим, выписки процессить в биллинге, каталоги поставщиков разбирать парсером, и задач по крону бегает штук 20
Ага, а потом какой-нибудь чудак залезет и поправит код прямо там. Вот совсем недавно видел такое, руки бы поотрывать.Что про vendors в репе, тут скорее "так принято"
А чем он лучше хуже acme.sh ?dehydrated
Не ну, помню, однажды джуниор из другого офиса закоммитил в мастер правки нескольких классов в старом коде, и заметили это через месяц при полном тестировании. И тесты видел, которые проверяли, чтобы код работал с ошибкойАга, а потом какой-нибудь чудак залезет и поправит код прямо там. Вот совсем недавно видел такое, руки бы поотрывать.
В enterprise есть такое понятие - baseline образ(ы).Рассматриваю php бинарь и исходный код как неразделимые части и именно это называю приложением. Пхп бинарь, это не только echo, но еще набор расширений специфичных для исходников, а бывает, что специфичных версий.
ну являются ли внешние библиотеки, обязательные для исполнения - частью приложения или нет? А считаю, что являются. И ext из php из той же серии. Возможность менять или не менять их - это так себе критерий. В твоем коде тоже могут быть места, которые не меняют в минорном и ждут мажорного. Я различаю vendors и src лишь определенными внутренними политиками на изменение кода в рамках команды приложения. И эти политики удобно реализовывать, когда пакеты из vendors сделаны независимыми модулями.vendors - это и не часть baseline, и не часть приложения. Это артефакты. Самовольного обновления библиотек или фреймворков без согласования с лидом/директором в проекте быть не должно даже начиная с двух разработчиков в одном приложении. А директор разработки сначала согласует это с графиком релизов и другими разработчиками, прежде чем утвердить.
К примеру, в минорную версию новый фреймворк не пойдет, а в следующую полугодичную - можно.
Ну решается внутренними проксями. В целом я не вижу серьезных профитов в обоих вариантах. Да, vendors в репе удобнее для сборки деплоя, но не критично. Да, vendors вне репы уменьшает размер репы и защищает он частных изменений (пофиксили баг руками, остальные 100 сервисов с этим пакетом - живут с багом), т.е. по сути делает деление на модули, которое иначе бы пришлось делать сабмодулями или чем-то подобным.Сборка ни при чем. Собирать на самом деле удобнее, когда vendors в репе - не думаешь, и все. Однако, в enterprise-среде vendors всегда в репе Там просто нельзя брать их со сторонних ресурсов - все сервера за firewall.