Gitlab CI/CD простого проекта?

Question

[Artem0071]

В общем сделал небольшой проект на ларавеле. Нужно его каким то образом теперь развернуть
Сам по себе проект простой, можно и руками все развернуть, но очень хочется все автоматизировать..

Арендовал значит я сервер, разобрался с ансиблом, удалось даже загрузить и запустить docker с docker-compose на сервере

Сам файл playbook.yml

---
- hosts: all
become: true
gather_facts: no
tasks:
- name: Install aptitude
apt:
name: aptitude
state: latest
update_cache: true

- name: Install required system packages
apt:
pkg:
- apt-transport-https
- ca-certificates
- curl
- software-properties-common
- python3-pip
- virtualenv
- python3-setuptools
state: latest
update_cache: true

- name: Add Docker GPG apt Key
apt_key:
url: https://download.docker.com/linux/ubuntu/gpg
state: present

- name: Add Docker Repository
apt_repository:
repo: deb https://download.docker.com/linux/ubuntu focal stable
state: present

- name: Update apt and install docker-ce
apt:
name: docker-ce
state: latest
update_cache: true

- name: Install Docker Module for Python
pip:
name: docker

- name: Install Docker Compose
apt:
name: docker-compose
state: latest
update_cache: true

Теперь застопорился на моменте с деплоем
В проекте юзается докер, так что хочется чтобы в .gitlab-ci как то использовался он же, а не прописывать по новой какие то имаджи но не понимаю как

Что вообще хочется, так это то, чтобы все как то отдельно сбилдилось, затем прогнались тесты, затем отдельно на стейдж, затем отдельно на прод (да, прям вот так вот по взрослому хочется)

Как я это все вижу:
Билдится отдельно фронт и бек - но не очень понятно как, ведь все в одном docker-compose по сути
Затем прогоняются тесты - прочитал про артефакты, не очень понял как из предыдущего этапа достать тот самый докер..
Пребилд стейджа - запуск плейбука только для стейджа (удостовериться что докер установлен)
Билд стейджа - перекидывание докер образа (но ведь docker-compose.. не понимаю как работать должно) + docker-compose up видимо
Пребилд прода + билд прода - все то же что на стейдж, но только на прод

Upwork забанен, но очень нужно чтобы кто то объяснил все целиком.. По частям понимаю, как объединить все в одно - нет

Comments

[キム ファイブプラス]

gitlab

Где? Публичный или свой?

Пребилд

Что это значит?

удостовериться что докер установлен

Где? Если это стейджевый сервер, но нем уже должен быть установлен докер.

перекидывание докер образа

Откуда куда? (возвращаемся к первому вопросу)

playbook.yml. проект на ларавеле

Как это связано? Вы точно понимаете зачем нужен докер?

[Artem0071]

Публичный
По остальным вопросам я как раз и спрашиваю как делать

[キム ファイブプラス]

Artem0071, Ясно. Удачи.

Answer 1

[d-stream]

ну примерно вот так:

image: # имя докер-образа 

stages:
  - build
  - tests
  - deploy

build_my_project:
  stage: build
  tags: 
    - тэг раннера где запустить
  script:
    - ... # собственно действия для билда
    - ... 
    - ...
    - ...
  artifacts:
    name: как будет обзываться артефакт сборки
    paths:
    - путь до файлов в артефакт
    expire_in: 1 hour # сколько ему жить
test1: 
  stage: tests
  tags: 
    - тэг раннера где запустить
  needs:
    - build
  scripts:
    - # действия по выполнению теста

test2: 
  stage: tests
  tags: 
    - тэг раннера где запустить
  scripts:
    - # действия по выполнению теста 2

deploy_to_dev:
  stage: deploy
  tags: 
    - тэг раннера где запустить
  needs:
    - tests
  rules:
    - if: $CI_COMMIT_BRANCH == "development"
  scripts:
    - # действия деплою в dev


deploy_to_prod:
  stage: deploy
  tags: 
    - тэг раннера где запустить
  needs:
    - tests
  rules:
    - if: $CI_COMMIT_BRANCH == "master"
  scripts:
    - # действия деплою в dev

словами: на первом шаге - build выполнится то что прописано в scripts (последовательно, по строкам)
на втором шаге - test - параллельно выполнится два (ну или сколько надо блоков тестов)
на третьем - deploy - выполнится или deploy_to_prod или deploy_to_dev или ничего в зависимости от того в какой ветке идет сборка ($CI_COMMIT_BRANCH)
image: # имя докер-образа - имя соответсвующего docker-образа с подготовленной средой разработки (node:14 - для npm, mcr.microsoft.com/dotnet/sdk:6.0 - для .net6 и так далее)
можно и любой свой

needs: - описывает от каких шагов зависит шаг (это относительно свежее, ранее более жесткое dependencies:)

Comments

[Artem0071]

Спасибо конечно за самый базовый .gitlab-ci, который находится прямо в документации, но у меня вроде как вполне конкретный вопрос был.
Еще раз, как использовать не "имя соответсвующего docker-образа с подготовленной средой разработки", а конкретно то, что написано в docker-compose файле? Чтобы если я его поменял там, то не пришлось трогать gitlab-ci файл, а указать только имя сервиса
Вот как раз про эти "# собственно действия для билда", "# действия по выполнению теста", "# действия деплою в dev" и есть вопрос

Answer 2

[Vitaly Karasik]

Я не работал с GitLab (Jenkins, GitHub workflows, AWS Codebuiuld, TravisCI, ...), но в целом все одинаково.

1) Первое и главное - расписать и проделать вручную все что должен делать CI pipeline. Советую начать с самого простого - просто построить образ и задейлоить на сервере. Потом добавлять проверки и проч. - вариантов много https://qna.habr.com/q/1016852#answer_1981278. И добавлять разные вариации для разных branches and targets (типа - для master branch больше всего тестов и проч.)
Как деплоить - ИМХО, стоит это делать простыми контейнерами, без compose, тогда можно будет деплоить всюду - это сегодня самый универсальный формат.

2) Когда четко знаем что - искать как это имплементировать в gitlab или другом инструменте, сочинить самый простой сценарий, отладить, добавать что-то посложнее, отладить, и т.п.
Все как с программированием.
Примеров в интернете много.

Answer 3

[Александр Негашев]

GitLab autodevops, гуглим, смотрим видосики