Comments 15
А не проще выполнить этот питон скрипт обновления контейнера по ссш а не дергать через веб хук?
Если Вы имеете ввиду заходить скриптом по ssh и пулить/запускать контейнер, то примерно от этого я и пытался уйти.
В моем скрипте фласка от силы строк 20-25. От того же paramiko был бы не сильный выигрыш, да и не количеством строк мерятся надо. Плюс я использую dedicated сервер, и мне бы пришлось через pfsense пробрасывать ssh, что не есть хорошо.
А с веб сервисом от меня не требуется мануальных действий, результат я получаю гораздо быстрее, я могу развивать его(расширяя api), а также собирать различные метрики для сравнения различных подходов.
Если вы имели ввиду, собирать дополнительный контейнер на стороне гитхаба, и в нем поднимать ssh соединение, то это сильно усложнило бы процесс.
Т.е. контейнер должен подключиться по ssh и запускать тот же самый скрипт или хуже, удаленно запускать докер команды. Не думаю что это хороший подход.
Надеюсь ответил на ваш вопрос
Вопрос: тесты ведь планируется запускать для всех бранчей, а чекат делается только из мастера?
tags:
- '!refs/tags/*'
branches:
- '*'...
steps:
# Чекаутим код
- uses: actions/checkout@master
...Наверное чекаут нужно по другому написать?
Если бы GitHub Actions еще не проглючивали один раз из 30 примерно, вообще было бы отлично. Но, может, починят.
По статье: тесты по-хорошему надо бы в контейнере запускать, который только что собрался, перед его публикацией. А не снаружи. А то может быть, что контейнер собрался битый по какой-то причине, и каюк. Continuous Deployment превратится в «Нет повести печальнее на свете, чем повесть о заклинившем ресете».
Но и не стоит забывать, это ни в коем случае не production ready, это исключительно для знакомства с actions и маленьких домашних проектов.
По поводу глюков, я пробовал различные возможности и много баловался с yaml. Сумарно примерно 100-150 коммитов, но никаких зависаний и падений не заметил.
Спасибо за статью. Благодаря вам стало понятно, что если использовать нативные средства, то Gitlab CI поудобнее из за наличия Gitlab runner. Ни каких дополнительных сервисов, просто берём раннер и пишем под него скрипты теста-сборки-деплоя-откатов
Но в любом случае мало компаний, готовых хранить код в GitHub. По этому альтернатив gitlab'у
очень мало
В любом случае, в хранилищах артефактов docker api одинаковое, и перейти на другой registry не составит труда.
Спасибо, что показали ещё одну фичу гитхаба)
Бегло прочитав про Travis пришел к выводу, что в нем удобно собирать и тестировать, но доставку с ним особо не придумаешь.
Вообще travis из коробки поддерживает довольно большое количество возможностей по деплою (линк), так что придумывать ничего не надо.
Но actions не панацея, думаю выбор инструмента должен зависеть от проекта.
Спасибо за линк, как раз думал что-нибудь попробовать с lambda.
Строим домашний CI/CD при помощи GitHub Actions и Python