Спасибо!

Не расскажите поподробнее почему именно использование latest в туториале в конкретных местах где он исползован не к месту?

Времени ушло много, но урывками, поэтому затрудняюсь сказать сколько в сумме.

в локальном докере
docker images

💡 Если вы захотите обновить образ Pod в Kubernetes, потребуется этот Pod пересоздать. Для API это можно сделать, например, этой командой.

kubectl rollout restart deployment gitlab-course-api -n gitlab-course

....потребуется выполнить kubectl apply ещё раз, указав sha256 явно, добавив к имени образа конструкцию @sha256:<hash>.

Я прямо сейчас веду лабу по OpenShift, и могу заверить, что это был скорее умный вопрос :)

промахнулся

вообще у вас заведомо неверный origin. Зайдите через http://34.120.167.0.nip.io

не могу найти ошибку, выполните
kubectl get ingress -o yaml
спасибо

тут была чепуха

...или вы что-то делаете неправильно.

У вас SPA и API должны быть на одном хосте, и роутиться на основе path. Вы никак не можете получить CORS error если всё сделали правильно.

Тут было замечание что reactjs не фреймворк, я что-то нажал, и оно куда-то пропало. Не смотря на то, что команда reactjs любит подчёркивать что reactjs не фреймворк, а "маленькая библиотека для UI", reactjs именно что является фреймворком по определению. Умеющий читать да поймёт
https://en.wikipedia.org/wiki/Software_framework

Frameworks have key distinguishing features that separate them from normal libraries:

и далее по тексту

Как это противоречит multistage сборке из одного файла?

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

Тем что кеш слоёв не переиспользуется между джобами build_spa_builder и build_spa?

1. --cache-from позволил бы вам, например локально использовать кэш слоёв из multistage, как вы приводите в примере. Дело тут в неочевдном для докера образе а не в том что вы что-то там включили. В приведённом варианте он совсем не нужен т.к. derived образы прямо унаследованы.

2. dind runner в GitLab в принципе не умеет передавать кэш между job'ами. Ни в туториале ни у вас полного pull избежать не удастся.

>Что мешало оставить один докерфайл, вместо 3х.

Возможно, тот факт что финальный образ легковесный и не построен на среде сборки?

>Для второго переиспользовать слои из первого и указывать entrypoint

Там буквально замечание что так можно сделать. Объяснять как передавать команду при запуске контейнера сложнее чем указать другой докерфайл. Технически это то же самое.

>Для финального переиспользовать слои из первого.

Чем конкретно предложенная команда с --cache-from лучше того что и так просходит в докерфайле финального образа? Там двухэтапная сборка.

Как интеграционные тесты проводите?

У вас один Dockerfile на pipeline?

Спасибо за спасибо!

Спасибо за содержательный вопрос.
- envsubst есть не везде и в образе gitlab, который мы используем его нет
- kubectl kustomize - чтобы не объяснять ещё и kustomize, туториал вышел и так длинным

перед Kubernetes? Мы развёртываем приложение а не Kubernetes

1. Вместо Ansible у нас и так YAML Kubernetes, bash используется только для работы с утилитами типа docker, kubectl, git. Ansible тут не поможет.

2. В GKE вы платите за виртуальные машины worker nodes которые вы используете в Google Compute Engine. Непродуктивный вариант из туториала будет стоить как-то так.
   https://cloud.google.com/products/calculator#id=2004b345-10a8-479b-8986-4f0f50e7d363