Комментарии 21
gitlab? - не, не слышал.
Не понял тебя, объяснишь ?
Существует открытый проект gitlab, хостинг для git репозиториев с автоматизацией. В нем встроен хостинг docker образов. Для автоматизации в gitlab придуман .gitlab-ci.yml файл в корне проекта.
Вот рабочий пример для небольшого проекта
variables:
DEPLOY_TARGET: ec2-user@ec2-1-1-1-1.eu-central-1.compute.amazonaws.com
DEPLOY_DIR: ~/deploy/${CI_PROJECT_NAME}
stages:
- build
- deploy
build:
stage: build
script:
- docker login ${CI_REGISTRY} -u ${CI_REGISTRY_USER} -p ${CI_REGISTRY_PASSWORD}
- docker build -t ${CI_REGISTRY_IMAGE}:latest .
- docker push ${CI_REGISTRY_IMAGE}:latest
only:
- master
deploy-production:
stage: deploy
script:
- ssh -o StrictHostKeyChecking=no $DEPLOY_TARGET "mkdir -p $DEPLOY_DIR"
- scp -o StrictHostKeyChecking=no ${DOCKER_COMPOSE_PROD} $DEPLOY_TARGET:$DEPLOY_DIR/docker-compose.yml
- ssh -o StrictHostKeyChecking=no $DEPLOY_TARGET "cd $DEPLOY_DIR; docker login ${CI_REGISTRY} -u ${CI_REGISTRY_USER} -p ${CI_REGISTRY_PASSWORD}; docker-compose pull; docker-compose up -d;"
only:
- master
Скрипты выполняются на раннере, перед выполнением гитлаб сгенерирует пару login+password для доступа к текущему репозиторию и его реестру (она будет действительна до конца выполнения скриптов), с их же помощью склонирует репозиторий в свежую папку и начнет выполнять скрипты.
У вас проект доставляется репозиторием, вместо образа. Нет хранения актуального образа с прода. Стопается контейнер, а потом собирается, когда сборка должна быть до остановки старого (docker-compose сам умеет стопать старый контейнер). Отдельные шелл файлы не нужны, в крайнем случае в Makefile их можно засунуть.
Спасибо, что ответили за меня. Не хотелось расписывать:))))))
И как это позволит, например, развернуть проект локально одним скриптом?
Это требует значительно больших ресурсов и сил. Нужно и гитлаб развернуть, раннеры запустить, поддерживать все это дело.
В итоге это решает проблему более красиво и качественно, но затраты тоже намного больше.
Плюс не всегда есть вообще возможность развернуть где-то свой гитлаб по разным причинам, начиная от запросов заказчика, заканчивая банальным отсутствием ресурса, чтобы его развернуть и поддерживать.
Плюс это нужно уметь делать, что также требует или компетенции или времени на освоение.
Поэтому с моей точки зрения это не решает задачу, поставленную вначале статьи.
Да и чтобы эти конфигурации написать, нужно также время или опыт в этом.
Зачем разворачивать свой gitlab? Есть же публичный бесплатный вариант, кроме того есть бесплатный GitHub Workflows.
`Плюс это нужно уметь делать, что также требует или компетенции или времени на освоение.`
Да, IT это постоянно получение новых знаний и навыков.
Имхо для локальной разработки в одну каску - норм, но для командной работы выглядит слабо с кучей минусов (не зря же появились CI/CD инструменты с кучей готовых либ и Best Practices?).
Как аналогия, для меня это выглядит как заливание файлов по FTP на сервер...
Спасибо за статью, интересно было взглянуть как разработчики без опыта DevOps смотрят на проблему автоматизации.
Параметры для запуска Spring Boot приложения можно не передавать через -D в командной строке, а использовать сразу переменные окружения, приведя их имена к определенному виду. Например, spring.datasource.password станет SPRING_DATASOURCE_PASSWORD. Это упростит строку запуска до `java -jar app.jar`.
> Важно отметить, что переносить элементы этого массива на другую строку нельзя, потому что это все ломает
Можно использовать \ перед переводом строки
@Data не используется на entity
@Repository тоже не нужен
на мой взгляд при каждом старте поднимать пустую БД и создавать таблицы (spring.jpa.hibernate.ddl-auto=create) не самая лучшая задумка. И таблицы будут пустые.
На мой взгляд лучше сделать свой Docker - образ БД (сразу с таблицами и необходимыми данными) и при старте нужно будет просто поднять свой образ
Интересный факт - ‘git pull’ из листинга выше обновляет только текущую ветку. Поэтому тут надо либо сначала делать ‘git checkout’, а потом - ‘git pull’, либо сразу - ‘git pull -all’.
Очь веселое чтиво)
Согласен, сам только весной этого года окончательно закрепил знания по всему этому DevOps добру (docker, docker-compose, впереди еще k8s), правда на базе .NET.
Очень интересно наблюдать, как другие "дачники" проходят по этому пути, и пишут "я тоже покрасил свой забор".
Не думал, что по этому поводу даже нужно писать статьи на хабре.)
Даже не спрашивайте меня как это работает - я честно скоммуниздил это дело на stackoverflow))
Переменно rc (return code) присваивается код возврата исполнения предыдущей команды, mvc install, потом это код проверятся на то, отличен ли он от нуля (если код возврата не равен нулю, то это значит, что команда исполнилась с какой-то ошибкой). и если да, то скрипт завершает свою работу, передавая этот код возврата в среду исполнения.
Как программист настроил автоматическое развертывание бекенда с базой данных