Comments 32
Спасибо за статью - полезно, что думаете если bash скрипты заменять на что - то вроде ansible? И можете пожалуйста подсказать (если это известно), сколько примерно в месяц будет обходиться Google Cloud для такой конфигурации?
Вместо Ansible у нас и так YAML Kubernetes, bash используется только для работы с утилитами типа docker, kubectl, git. Ansible тут не поможет.
В GKE вы платите за виртуальные машины worker nodes которые вы используете в Google Compute Engine. Непродуктивный вариант из туториала будет стоить как-то так.
https://cloud.google.com/products/calculator#id=2004b345-10a8-479b-8986-4f0f50e7d363
Букву "В" из заголовка убрать бы
sed "s/{{NAMESPACE}}/gitlab-course/g" ingress.yml
А почему именно sed?
Варианты: kubectl kustomize или envsubst
Использую для простых и средних диплоев автодевопсот гитлаба, киллер фича
Решение в том чтобы разделить нашу двухэтапную сборку на сборку 2-ух образов — "побольше" и "поменьше".
Что мешало оставить один докерфайл, вместо 3х.
Для первого этапа указывать stage builder
Для второго переиспользовать слои из первого и указывать entrypoint
Для финального переиспользовать слои из первого
docker pull "$CI_DOCKER_BUILDS_REGISTRY/$CI_BRANCH/$CI_PROJECT_TITLE:YOUR_BRANCH_NAME" || true
docker build --cache-from "$CI_DOCKER_BUILDS_REGISTRY/$CI_BRANCH/$CI_PROJECT_TITLE:YOUR_BRANCH_NAME" --target prod_image --tag "$CI_DOCKER_BUILDS_REGISTRY/$CI_BRANCH/$CI_PROJECT_TITLE:$PRODUCT_VERSION" .
>Что мешало оставить один докерфайл, вместо 3х.
Возможно, тот факт что финальный образ легковесный и не построен на среде сборки?
>Для второго переиспользовать слои из первого и указывать entrypoint
Там буквально замечание что так можно сделать. Объяснять как передавать команду при запуске контейнера сложнее чем указать другой докерфайл. Технически это то же самое.
>Для финального переиспользовать слои из первого.
Чем конкретно предложенная команда с --cache-from лучше того что и так просходит в докерфайле финального образа? Там двухэтапная сборка.
Возможно, тот факт что финальный образ легковесный и не построен на среде сборки?
Как это противоречит multistage сборке из одного файла?
Чем конкретно предложенная команда с --cache-from лучше того что и так просходит в докерфайле финального образа? Там двухэтапная сборка.
Тем что кеш слоёв не переиспользуется между джобами build_spa_builder и build_spa?
Вот есть полезный материал по этой теме.
Как это противоречит multistage сборке из одного файла?
Ваше предложение уменьшает количество докерфайлов за счёт усложнения работы с ними. Т.е. это просто другой компромисс, а не оптимизация. Попробуйте взять и внятно описать процесс с использоваем слоёв из двухэтапной сборки, и посмотрите получится ли короче, не понадобится ли по дороге объяснять про слои, чего в туториале удалось избежать. Плюс мы по факту так и так запускаем тесты в другом контейнере, на основе слоёв spa_builder.
Тем что кеш слоёв не переиспользуется между джобами build_spa_builder и build_spa?
--cache-from позволил бы вам, например локально использовать кэш слоёв из multistage, как вы приводите в примере. Дело тут в неочевдном для докера образе а не в том что вы что-то там включили. В приведённом варианте он совсем не нужен т.к. derived образы прямо унаследованы.
dind runner в GitLab в принципе не умеет передавать кэш между job'ами. Ни в туториале ни у вас полного pull избежать не удастся.
Тут было замечание что reactjs не фреймворк, я что-то нажал, и оно куда-то пропало. Не смотря на то, что команда reactjs любит подчёркивать что reactjs не фреймворк, а "маленькая библиотека для UI", reactjs именно что является фреймворком по определению. Умеющий читать да поймёт
https://en.wikipedia.org/wiki/Software_framework
Frameworks have key distinguishing features that separate them from normal libraries:
и далее по тексту
походу никто не выполнил развертывание в GKE, потому как у меня CORS проблема как была как и осталась
Access to fetch at 'http://34.120.167.0.nip.io//log' from origin 'http://34.120.167.0' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource. If an opaque response serves your needs, set the request's mode to 'no-cors' to fetch the resource with CORS disabled....или вы что-то делаете неправильно.
У вас SPA и API должны быть на одном хосте, и роутиться на основе path. Вы никак не можете получить CORS error если всё сделали правильно.
тут была чепуха
вообще у вас заведомо неверный origin. Зайдите через http://34.120.167.0.nip.io
шпасибо!
это стоило мне 30мин моей жизни ))) я не мог обновить образ, потому как накосячил со слэшами в первом образе, но все равно спасибо огромное!
? Если вы захотите обновить образ Pod в Kubernetes, потребуется этот Pod пересоздать. Для API это можно сделать, например, этой командой.
kubectl rollout restart deployment gitlab-course-api -n gitlab-course....потребуется выполнить kubectl apply ещё раз, указав sha256 явно, добавив к имени образа конструкцию @sha256:<hash>.
Спасибо за интересный гайд с большим количеством подробностей !
Из пожеланий:
не использовать тег latest
скрыть под кат yaml конфиги, они слишком объемны
использовать кликабельные оглавления в таких больших статьях
Сколько времени ушло на написание статьи, если не секрет ?
Развёртывание в Kubernetes из GitLab