Лучшие практики CI/CD с Kubernetes и GitLab (обзор и видео доклада)

[stagor]

Спасибо за интересную статью. Очень содержательно.
Вопрос: у нас на проекте используется webpack (react + redux). Каждый энвайронмент имеет свои URLы, что отображено в конфигах. Разработчики убеждают, что надо билдить несколько образов под каждый энвайронмент. Вы встречались с подобным? Мне не нравится идея, что приходится деплоить один образ в тестовое окружение, другой образ в пре-прод и третий образ в прод и все только потому, что webpack зашифает конфигурацию как адреса апи-сервисов, где лежат ассеты и т.д.

[stas]

Вы можете модифицировать конфиги в скрипте ENTRYPOINT вашего контейнера. В случае с Kubernetes можно попробовать использовать initContainer, выполняющий примерно те же функции что и скрипт в ENTRYPOINT или даже configMap, содержащий ваши конфиг(и).

[stagor]

Эм, тогда в контейнере мне надо будет сохранять и секреты, чтобы можно было модифицировать под каждый энвайронмент.
Вы считаете, это хорошая практика ребилдить приложение с webpack при инициации имиджа в контейнер?

[stas]

Я последний раз касался webpack'а довольно давно и вскользь, если честно. Наш билд производил некий generic (по факту, нерабочий) config.json, который каждый раз заменялся сгенерированным при старте контейнера скриптом из ENTRYPOINT:

#!/bin/sh

cat << EOF > /app/config.json
{
  "some_url": "${SOME_URL}",
  "some_secret": "${SOME_SECRET}",
  "key": "${VALUE:-default_value}"
}
EOF

...
exec "$@" # or just nginx

Соответственно, при деплое контейнера достаточно выставить все переменные и конфиг будет сгенерен. Вместо большого template в коде скрипта можно использовать sed и заменять параметры in-place в существующем конфиге. В любом случае, идея такая что образ всегда один и тот же, а конфиг модифицируется скриптом при старте.

[stagor]

Да, вот этот подход с webpack'ом как мне кажется не получится. Потому что сначала надо запустить `yarn install`, потом `yarn build`. У нас SPA, клиента надо будет загрузить на Storage, а сервер надо будет еще раз инициализировать уже с `yarn install -p`. Много телодвижений.

Я сделал следующим способом. ТимСити у меня запускает и тестирует приложение, тесты, линт все дела. Если все хорошо, то он создает пакет из исходников и отправляет пакет в Октопус. Октопус уже распаковывает на машине, где установлен kubectl, и производить сборку под окружение, и делает основной деплоймент.

Спасибо.

[DuD]

Подниму старый тред)
Я сам долго бился с подобными заявками от разрабов. В итоге пришли к тому что во все URL прописываем относительный путь, чаще всего что-то вроде /api.

А в одном очень крупном банковском проекте делают более креативно. Тупо через sed по уже собранному коду прогоняют замену домена на нужный.

[decay_of_mind]

distol Привет! Как я понял, у вас «пакет» хельма лежит в папке проекта в `.helm/`. А вопрос такой — вы когда деплоите например сервис на Python, которому нужен наприемер Redis в кластере, то у вас Redis описан в этом же пакете? Или указан как зависимость? Или вообще не указан и вы его деплоите отдельным джобом?

[distol]

В этом же пакете.