Vendors в git

fixxxer · 16 Июл 2019

Ага. Ну, конкретно с cron-ом может понадобиться и еще один (обычно-то крон там нафиг не нужен). Впрочем, с современными фреймворками, подразумевающими единственную запись в кроне вида * * * * * php artisan schedule:run, достаточно тупого шелл-скрипта.

grigori · 16 Июл 2019

вот реально комсомольцы - придумали усложнения, и убежденно доказывают, что проблемы нужны, они могут только в гамаке, стоя, и в образе

WMix написал(а):
А дальше тотже docker-compose up

Compose на проде. На единственной машине без репликаций, без failover, бекап базы на мастере. Удачи.
Или на проде все-же kubernetes/stack, а ты все аргументы выдумал, тебе просто сказали заливать образ вместе с исходниками в registry, а что там дальше - тебя не касается?

grigori · 16 Июл 2019

AnrDaemon написал(а):
Вот кстати что меня ещё в Докере беспокоит. Крон и подобные процессы непонятно как запускать правильно.

Думаю статью с репозиторием решения написать. Попробвали несколько вариантов вместе с devops-ом, нормальное решение - это Docker-in-Docker . https://hub.docker.com/_/docker

Например, надо продлять сертификаты certbot-ом. Почему в докере - потому что эта сука certbot устаревает и перестает работать через год-два, его надо обновлять регулярно, а новым версиям нужна новая OS, и в каком-то ином виде, кроме как в образе докера, он просто ненадежен. Вон на форуме тоже недавно сертификат слетал.

В stack.yml пропитывается такой сервис

YAML:

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

тут, как видно, монтируются crontab и scripts, в переменной прописан список доменов

в bash-скрипте по крону вызов вида

Bash:

    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}

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

fixxxer · 16 Июл 2019

У меня есть решение проще - в задницу certbot, из задницы dehydrated.
Шелл-скрипт обновить безо всяких докеров-в-докерах можно.

А отвалиться может вообще все что угодно - ну так мониторинг никто не отменял.

grigori · 16 Июл 2019

стоит попробвать dehydrated, спасибо

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

а как ты мониторишь, обновил ли через 2 месяца скрипт сертификат по крону, или слетел по ошибке API?
почтовый сервис не хочется на host ставить, он там не нужен

я вчера нашел решение под названием cloudfront - он сам ставит у себя сертификат для моего домена, а мне для сервера дает внутренний на 15 лет, и никаких продлений

правда, он целиком падал недавно

grigori · 16 Июл 2019

fixxxer написал(а):
С современными фреймворками, подразумевающими единственную запись в кроне вида * * * * * php artisan schedule:run, достаточно тупого шелл-скрипта.

к сожалению, гомогенную среду, где все запускается через artisan schedule:run, найти все сложнее,
чаще надо рассылки отправлять одним приложением, сертификаты продлять другим, выписки процессить в биллинге, каталоги поставщиков разбирать парсером, и задач по крону бегает штук 20

сейчас вместо крона лучше написать долгоживущий процесс со sleep, он может просто завершаться раз в несколько дней, а докер поднимет новый контейнер,
но если у нас 20 job-ов на кроне, их надо как-то портировать в докер, иначе они базу по overlay-сети не увидят,
а если 5 задач в одном контейнере - проблема с логами

так что вариант с docker-in-docker- нормально, потому что 1 раз написал, и не надо крон на сервере настраивать, и все отдельно работает

fixxxer · 16 Июл 2019

grigori написал(а):
а как ты мониторишь

Снаружи. Смотрю expiration сертификата, если явно уже должен был обновиться, но не обновился - значит, что-то не так.

grigori написал(а):
чаще надо рассылки отправлять одним приложением, сертификаты продлять другим, выписки процессить в биллинге, каталоги поставщиков разбирать парсером, и задач по крону бегает штук 20

...и еще это все горизонтально отмасштабировать, да.

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

Не, я против docker-in-docker ничего не имею, просто это на тот случай, когда иначе никак.

MiksIr · 16 Июл 2019

Рассматриваю php бинарь и исходный код как неразделимые части и именно это называю приложением. Пхп бинарь, это не только echo, но еще набор расширений специфичных для исходников, а бывает, что специфичных версий. Да и деплой удобнее, никаких забот про инвалидацию опкеша и т.п. Соответственно composer install при сборке. Проблема наличия composer.phar не беспокоит, но если вдруг у кого-то пунктик - мультистейджовые билды.

Что про vendors в репе, тут скорее "так принято" и наличие хорошего продукта, не доставляющего особых проблем. Наверное, можно упомянуть еще не очень красивые diff-ы, когда в ветку решения задачи пойдут изменения обновленного пакета, не относящиеся к задаче.

fixxxer · 17 Июл 2019

Конкретная версия MySQL тоже может быть нужна, это тоже часть "приложения"?

Как по мне, приложение - это то, что в docker-compose. А контейнеры - это его модули. Как на них делить - да как удобнее, так и делить.

fixxxer · 17 Июл 2019

MiksIr написал(а):
Что про vendors в репе, тут скорее "так принято"

Ага, а потом какой-нибудь чудак залезет и поправит код прямо там. Вот совсем недавно видел такое, руки бы поотрывать.

Yoskaldyr · 17 Июл 2019

fixxxer написал(а):
dehydrated

А чем он лучше хуже acme.sh ?

fixxxer · 17 Июл 2019

Да вроде один фиг, на первый взгляд. Dehydrated просто первый был (letsencrypt.sh раньше назывался), я к нему привык.

grigori · 18 Июл 2019

fixxxer написал(а):
Ага, а потом какой-нибудь чудак залезет и поправит код прямо там. Вот совсем недавно видел такое, руки бы поотрывать.

Не ну, помню, однажды джуниор из другого офиса закоммитил в мастер правки нескольких классов в старом коде, и заметили это через месяц при полном тестировании. И тесты видел, которые проверяли, чтобы код работал с ошибкой

Запретили коммиты в мастер. Это вопрос другого уровня.

grigori · 18 Июл 2019

MiksIr написал(а):
Рассматриваю php бинарь и исходный код как неразделимые части и именно это называю приложением. Пхп бинарь, это не только echo, но еще набор расширений специфичных для исходников, а бывает, что специфичных версий.

В enterprise есть такое понятие - baseline образ(ы).
Это сборка конкретного ядра, версий библиотек, версии бд, версии runtime (php, java, whatsever).
Обновление baseline - это отдельный процесс, который простым смертным разработчикам недоступен в принципе.
А приложение разработчики меняют. Разделение жесткое и логичное.

vendors - это и не часть baseline, и не часть приложения. Это артефакты. Самовольного обновления библиотек или фреймворков без согласования с лидом/директором в проекте быть не должно даже начиная с двух разработчиков в одном приложении. А директор разработки сначала согласует это с графиком релизов и другими разработчиками, прежде чем утвердить.
К примеру, в минорную версию новый фреймворк не пойдет, а в следующую полугодичную - можно.

Сборка ни при чем. Собирать на самом деле удобнее, когда vendors в репе - не думаешь, и все. Однако, в enterprise-среде vendors всегда в репе

Там просто нельзя брать их со сторонних ресурсов - все сервера за firewall.

Пытаюсь понять, нафига это развлечение с compose install.
Читаю, и фигею, сколько же дури вы тут навыдумывали.

fixxxer · 18 Июл 2019

Коммиты в мастер запретить - это понятно (удивительно, что они где-то разрешены).

Но никакой code review не спасет от ситуации, когда кто-нибудь обновил библиотеку и заодно что-то там поправил.

Вообще я конечно офигеваю, такая проблема сделать composer install с докером

Да десять способов можно придумать, как это сделать. А для сурового ентерпрайза есть Satis, в который все нужное элементарно миррорится.

Adelf · 19 Июл 2019

@grigori а фронтэндеры ваши держат в гите скомпиленные из тайпскрипта или чего другого js-ки? Скомпиленные css-ки? По твоим аргументам - должны)

Я сейчас, к сожалению на проекте где все держат там. и вендоры и скомпиленное. Как раз, чтобы все было готовое и не надо было каждому девелоперу компилить и инсталл делать. Но диффки смотреть некоторые - ужас. А про сложные мержи и говорить нечего.
Гит придумали и сделали не для удобного деплоя, а для хранения и удобного манипулирования собственных сорцов.

MiksIr · 19 Июл 2019

grigori написал(а):
vendors - это и не часть baseline, и не часть приложения. Это артефакты. Самовольного обновления библиотек или фреймворков без согласования с лидом/директором в проекте быть не должно даже начиная с двух разработчиков в одном приложении. А директор разработки сначала согласует это с графиком релизов и другими разработчиками, прежде чем утвердить.
К примеру, в минорную версию новый фреймворк не пойдет, а в следующую полугодичную - можно.

ну являются ли внешние библиотеки, обязательные для исполнения - частью приложения или нет? А считаю, что являются. И ext из php из той же серии. Возможность менять или не менять их - это так себе критерий. В твоем коде тоже могут быть места, которые не меняют в минорном и ждут мажорного. Я различаю vendors и src лишь определенными внутренними политиками на изменение кода в рамках команды приложения. И эти политики удобно реализовывать, когда пакеты из vendors сделаны независимыми модулями.

grigori написал(а):
Сборка ни при чем. Собирать на самом деле удобнее, когда vendors в репе - не думаешь, и все. Однако, в enterprise-среде vendors всегда в репе Там просто нельзя брать их со сторонних ресурсов - все сервера за firewall.

Ну решается внутренними проксями. В целом я не вижу серьезных профитов в обоих вариантах. Да, vendors в репе удобнее для сборки деплоя, но не критично. Да, vendors вне репы уменьшает размер репы и защищает он частных изменений (пофиксили баг руками, остальные 100 сервисов с этим пакетом - живут с багом), т.е. по сути делает деление на модули, которое иначе бы пришлось делать сабмодулями или чем-то подобным.

fixxxer · 19 Июл 2019

Я вообще не понимаю, как держать vendors в репе. А что делать с собственными зависимостями (вот написали либу и используем тут и там)? Копипастить везде, и когда баг поправили обновлять везде ручками? А с фронтендом что? Держать собранные css и js тоже в репе?

В любом случае в любом вменяемом проекте так или иначе будет система сборки, без этого же вообще невозможно. Чем там вообще мешает composer install?

С разработкой вообще никаких проблем быть не должно: если все не через задницу, разработчик запустил docker-compose up и все само сделалось.

Не, я понимаю, что кто-то там просто сайтики на вордпрессе клепает и по ftp заливает на шаред хостинг, но мы же не про такое говорим, правда же?

Ну или я понимаю, что у кого-то там исторически сложилось - монорепы на 100 терабайт и прочий идиотизм, но то, что кто-то усложнил себе жизнь и страдает, не повод страдать так же

AnrDaemon · 19 Июл 2019

Blog | Docker

Read our blog to find the latest Docker updates, news, technical breakdowns, and lifestyle content.

blog.docker.com

Последний тип.

grigori · 19 Июл 2019

о, наконец-то, спасибо! я уже отчаялся увидеть аргументы по теме, теперь буду думать

Vendors в git

К.О.

( ͡° ͜ʖ ͡°)

( ͡° ͜ʖ ͡°)

К.О.

( ͡° ͜ʖ ͡°)

( ͡° ͜ʖ ͡°)

К.О.

miksir@home:~$

К.О.

К.О.

"Спамер"

К.О.

( ͡° ͜ʖ ͡°)

( ͡° ͜ʖ ͡°)

К.О.

Administrator

miksir@home:~$

К.О.

Продвинутый новичок

( ͡° ͜ʖ ͡°)