git и deploy

Не использовать git для deploy

man .gitignore

Лорчую этого оратора.

Тебе нужен нормальный CI/CD. Смотри в сторону Jenkins, buildbot или gitlab/github.

Jenkins все что он делает - это билды и прочее там все равно скрипты на сколько я понимаю. gitlab как поможет?

ну так или иначе пусть даже кто-то будет деплоить другой к примеру мой скрипт он все равно вытянет из git. чем поможет сторонний софт?

gitlab + docker + docker-compose + gitlab-runner + .gitlab-ci.yml + .gitignore + .dockerignore

А дальше по пушу в ветку собираешь docker-образ без мусора, пушишь в registry, а на продуктовом вытягиваешь из registry только образы с кодом. Контент, базу и бэкапы(если надо) держишь в volumes.

Удачи.

Настройки CI/CD проекта в дженкинсе - богомерзкая гуйня. Настройка в гитлабе - православный .gitlab-ci.yml, который держишь прямо в гите проекта. Что-то вроде этого...

variables:
    CI_REGISTRY: registry.domain.org:443
image:
    name: docker/compose:1.21.2
    entrypoint: [""]

before_script:
    - apk add --no-cache make bash
    - echo  $CI_JOB_TOKEN | docker login -u gitlab-ci-token --password-stdin $CI_REGISTRY

stages:
    - build
    - deploy

build-dev:
    stage: build
    script:
        - docker-compose -f dockerize/build/docker-compose.develop.yml build
        - docker-compose -f dockerize/build/docker-compose.develop.yml push
    tags:
        - build_runner
    only:
        - develop

build-prod:
    stage: build
    script:
        - docker-compose -f dockerize/build/docker-compose.master.yml build
        - docker-compose -f dockerize/build/docker-compose.master.yml push
    tags:
        - build_runner
    only:
        - master

deploy-dev:
    stage: deploy
    script:
        - docker-compose -f dockerize/develop/docker-compose.yml pull
        - docker-compose -f dockerize/develop/docker-compose.yml down
        - docker-compose -f dockerize/develop/docker-compose.yml up -d 
    tags:
        - develop_runner
    only:
        - develop

deploy-prod:
    stage: deploy
    script:
        - docker-compose -f dockerize/master/docker-compose.yml pull
        - docker-compose -f dockerize/master/docker-compose.yml down
        - docker-compose -f dockerize/master/docker-compose.yml up -d 
    tags:
        - master_runner
    only:
        - master

Кстати, мне один анон рекомендовал полноценную замену гитлаба, но жрущую ресурсов в разы меньше. Что-то я не могу тот топик найти. Посоветуй ещё раз пожалуйста, возможно придётся у себя внедрять.

Тем, что соберёшь docker-образ со всем нужным и без всего ненужного при помощи .gitignore и .dockerignore, и дашь «кому-то» ссылку на registry + volumes с данными. И пусть хоть на кофеварку эти образы тянет и деплоит.

Может речь шла про gitea?

В точку. Оно. Легче и по фичам местами лучше, местами хуже. Сам ещё не знаю что точно пригодится.

Если нет нужны в CI\CD и иконках для проектов - gitea должно хватить.

в ci\cd есть нужда.

В принципе есть success story прикручивания к gitea чего-то вроде k3s («облегченный» кубер). Но это всё сторонние решения, из коробки CI поддерживает только gitlab.

Сам опыты по CI в gitea не проводил. Не надо, к счастью :)

спасибо за рекомендации.

а вот с таким кейсом - в проекте есть код и данные. данными считаются к примеру пользовательские изображения (аватарки) и файлы типа .bash_history которые изначально храняться на сервер - их можно оставить на сервере (делаются бекапы) а можно периодически класть в git (либо сразу с сервера либо через рабочую машину и механизм деплоя). как лучше?

также в проекте есть код - он в git, его можно утягивать на локальную машину и копировать (деплоить) на сервер либо сразу утягивать из гита на сервер без локальной машины тем же скриптом диплоя, как лучше, через локальмуню машину или можно сразу на сервер?

также в проекте есть всякие там вторичные файлы которые так или иначе берутся из других мест - это иконки, .js код, архивы .zip и прочие вещи - их надо «собрать» из разных мест и обновить на сервере, где-то это взять файл, где то распаковать архив и взять файл, где-то скомпилировать проект и взять конечный файл. сейчас это делается вручную с локальной машины. и опять же тут в гите эти данные не нужны, так как файлы эти вторичные (по отношению первичному исходному коду из которого они собираются), класть их в гит постоянно? нерезонно. так как бинарные файлы и перепакованные ахривы получаются все время разные и при каждой выкатке обновлять данные git по этому проекту - слишком накладно и не нужно на мой взгляд, так как файлы - вторичные. как быть?

то есть получается что в проекте есть нужнда для синхронизации как в сторону на сервер так и в сторону с сервера. и есть данные собираемые из других мест.

как лучше сделать в таком случае?

спасибо!

А зочем вам в репозиторий менеджере CI/CD? Есть же Buildbot, Concourse, Drone, дженкинс в конце-концов.

не понял вас если честно(

А я и не к вам обращался.

Мне оно как раз и не надо. Но знаю команды, которые деплоятся из gitlab.