Итоговый проект

О работе

Для выполнения лабораторной работы понадобятся:

• какой-нибудь ваш проект (например, курсовая по сетям, заготовки диплома или что-нибудь ещё);
• виртуальная машина с Kubernetes (результат прошлых лабораторных работ, Kubernetes тоже оттуда).

В результате лабораторной работы предстоит:

1. Запушить код вашего проекта в GitLab.
2. Настроить GitLab CI/CD.
3. На основе кода вашего проекта подготовить образ Docker.
4. Создать configmap, service, deployment и ingress в Kubernetes.
5. Настроить CI/CD для автоматического обновления.

Отчет

Отчет в формате docx. Обязательное содержимое отчета:

• Фамилия и инициалы студента, номер группы, номер варианта;
• План и задачи лабораторной работы;
• Краткое описание хода выполнения работы;
• Скриншоты результатов заданий.

Задание

1. Запушить ваш проект в собственный репозиторий на hub.mos.ru (в качестве альтернативы вы можете воспользоваться gitlab.com).

2. Включить CI/CD для вашего проекта.

3. Подключить Gitlab Runner к вашему проекту.

   Чтобы протестировать работу CI/CD вы можете создать тестовый .gitlab-ci.yml:

   job:
     script:
       - echo test

4. Упакуйте ваш проект в контейнер Docker. Для этого создайте Dockerfile и опишите подготовку вашего образа.

   Протестируйте сборку вашего проекта:

   docker build -t myimage_name:mytag ...

5. Сформируйте Pipeline CI/CD, состоящий из 3 стадий: build, upload, deploy. В качестве места для деплоя можно выбрать свою собственную виртуальную машину. На этой виртуальной машине можно развернуть свой Gitlab Runner в конфигурации shell. В качестве примера Pipeline вы можете использовать CI/CD, который используется для публикации данного руководства.

6. В стадии build создайте задачу build, в которой собирается образ и присваивается ему тэг по хешу его коммита:

   docker build -t myimage_name:$CI_COMMIT_SHORT_SHA ...

   script:
     - docker build -t myimage_name:$CI_COMMIT_SHORT_SHA ...

7. В стадии upload создайте задачу upload в которой загружаем наш образ в kind:

   script:
     - kind load docker-image myapp:${CI_COMMIT_SHORT_SHA}

8. В стадии deploy создайте задачу deploy:

   environment:
     name: production
   script:
     - kubectl get pods

   Деплой должен будет упасть, потому что не сообщили параметры подключения к кластеру. Откройте настройки проекта Settigns -> CI/CD -> Variables и создайте переменную с именем KUBECONFIG типа File, в environment scope должен был появиться наш production, и включить protected variable. Скопируйте значение вашего конфига из /root/.kube/config и вставьте его в значение переменной.

   Перезапустите Pipeline. CI/CD должен пройти и в логах увидеть список подов.

9. Создайте папку manifests, в ней либо один manifest.yml, либо несколько service.yml, deployment.yml, ingress.yml. Опишите манифесты для service, deployment и ingress. Также в корне проекта создайте папку etc или configs и скопируйте туда все конфиги приложения.

10. Создайте configmap:

    kubectl create configmap myapp-conf --from-file=< etc или config>/ --namespace=default -o yaml --dry-run=client | kubectl apply -f -

11. Задеплойте вручную первоначальные манифесты:

    kubectl apply -f manifests/

12. Обновите задачу deploy, чтобы обновлять конфиги и образ автоматически:

      script:
        - kubectl create configmap myapp-conf --from-file=< etc или config>/ --namespace=default -o yaml --dry-run=client | kubectl apply -f -
        - kubectl set image deployment/my-deployment mycontainer=myapp:${CI_COMMIT_SHORT_SHA}

13. Настройте CI/CD, чтобы задачи build, upload, deploy запускались только по коммиту в мастер.

    info

    Выполнение по данный пункт достаточно для сдачи работы. Далее пункты выполняются на свое усмотрение.

14. Настройте запуск тестов по открытому запросу на слияние.

15. При желании и свободном времени, можно изучить пакетный менеджер Helm и заменить задачу deploy на helm update.