Тогда нас поджимали сроки по сдаче некоторых проектов и в тот момент было проще и быстрее выпустить 2 версии. В одном из следующих релизов мы сделали это опцией настройки.
Процесс emergency patching начинаем, как только узнаём об уязвимости, требующей исправления. А после исправления сроки уже зависят от проверяющей лаборатории.
Есть хост с докером, в начале билда создаётся контейнер с пробросом sock, в него передаются сорцы (через вольюм или простым копированием), и внутри этого контейнера собирается итоговый образ через docker build... ?
Или сам контейнер создаётся на основе образа с компилятором и просто запускается башовая команда на компиляцию?
Лично нас кэш сильно выручает при выкачивании репозитория, а непосредстветвенно сборка у нас происходит при создании мультистейдж Docker образа - там всё чистенько. Плюс стоит настройка TeamCity, чтобы директория для билда чистилась перед сборкой.
С зависшими процессами лично мы не сталкивались, все шаги у нас можно разбить на 3 группы:
Подготовка аргументов. Это простейшие bash скрипты, там нечему зависать.
Собственно, сборка Docker образа. Сделано через обёртки TeamCity - при стопах билдов и тому подобному зависаний не заметили.
Если отвечать честно, то на момент внедрения не было специалиста с экспертизой в Ansible и аналогов, а компетентности в Docker было достаточно. И казалось, что "условно за день" можно справиться своими силами без изучения Ansible. Задача оказалось разовой, работает вполне годно, удовлетворяет наши потребности.
Если бы был человек, который знает Ansible, скорее всего тогда бы делали с его помощью.
Тогда нас поджимали сроки по сдаче некоторых проектов и в тот момент было проще и быстрее выпустить 2 версии. В одном из следующих релизов мы сделали это опцией настройки.
Процесс emergency patching начинаем, как только узнаём об уязвимости, требующей исправления. А после исправления сроки уже зависят от проверяющей лаборатории.
Мы как раз сейчас движемся в этом направлении. Версии 3.х будем так сертифицировать.
С proxy_pass надо быть очень аккуратным.
Конкретно в вашей конфигурации на страничке по ссылке http://192.168.44.76/server/files открывается как http://192.168.44.76/server
Я как-то больше привык к rewrite. Для меня он понятнее работает.
Да, с поддоменом прокатит.
Но хотелось ещё сделать конфигурацию для разработчиков, чтобы можно было просто по айпишнику обращаться.
Правильно ли я понял?
Есть хост с докером, в начале билда создаётся контейнер с пробросом sock, в него передаются сорцы (через вольюм или простым копированием), и внутри этого контейнера собирается итоговый образ через docker build... ?
Или сам контейнер создаётся на основе образа с компилятором и просто запускается башовая команда на компиляцию?
Судя по документации, у docker sock есть особенности при работе двух билд агентов на одном хосте, надо будет дополнительно настраивать.
И ещё из билда можно грохнуть контейнер билд агента.
Лично нас кэш сильно выручает при выкачивании репозитория, а непосредстветвенно сборка у нас происходит при создании мультистейдж Docker образа - там всё чистенько. Плюс стоит настройка TeamCity, чтобы директория для билда чистилась перед сборкой.
С зависшими процессами лично мы не сталкивались, все шаги у нас можно разбить на 3 группы:
Подготовка аргументов. Это простейшие bash скрипты, там нечему зависать.
Собственно, сборка Docker образа. Сделано через обёртки TeamCity - при стопах билдов и тому подобному зависаний не заметили.
Пуш в Docker Hub.
Спасибо, поправил.
Если отвечать честно, то на момент внедрения не было специалиста с экспертизой в Ansible и аналогов, а компетентности в Docker было достаточно. И казалось, что "условно за день" можно справиться своими силами без изучения Ansible. Задача оказалось разовой, работает вполне годно, удовлетворяет наши потребности.
Если бы был человек, который знает Ansible, скорее всего тогда бы делали с его помощью.
Да, можно сделать через traefik.
Я просто лучше знаком с nginx и решил сделать через более понятный мне инструмент.