В какой то момент разработки мы приходим к том, что нам нужно развернуть наше приложение на реальном сервере. Самый простой и долгий способ: собирать приложение локально, передавать на сервер по SFTP, затем по SSH рестартовать службу приложения (предварительно написанную для systemd). Хотелось бы меньше действий, щелкнул по кнопке и все само развернулось (CI/DI). Для этого можно написать свой сервис, найти готовое ПО типа Jenkins или использовать CI/DI от Github, который называется GitHub Actions. Рассмотрим вариант с GitHub Actions как самый быстрый в реализации.
Разворачивать будем приложение написанное на Go. Считаем, что арендованный VPS у нас уже есть. Я выбрал VPS на reg.ru с установленным образом Docker.
На наш сервер установим runner для GitHub Actions
Сперва создаем пользователя, т.к. под рутом нельзя запускать runner и включаем его в группу sudo
sudo useradd app -p mypassword
sudo usermod -a -G sudo app
sudo usermod -a -G docker app
Так же убедитесь, что у исполняемого файла /usr/bin/docker-compose стоят права 711 или 755 (разрешен запуск всем пользователям, а не только владельцу и его группе)
Логинимся под нашим новым пользователем. Далее следуем инструкции по добавлению своего runner, которая находится в настройках проекта github:
Из инструкции (копируйте команды из инструкции, там версия новее и url/token указан):
# Create a folder
$ mkdir actions-runner && cd actions-runner
# Download the latest runner package
$ curl -o actions-runner-linux-x64-2.304.0.tar.gz -L https://github.com/actions/runner/releases/download/v2.304.0/actions-runner-linux-x64-2.304.0.tar.gz
# Extract the installer
$ tar xzf ./actions-runner-linux-x64-2.304.0.tar.gz
# Create the runner and start the configuration experience
$ ./config.sh --url <ваш url github> --token <здесь ваш токен>
# Last step, run it!
$ ./run.sh
После запуска отвечаем на несколько вопросов установщика и runner готов.
Далее запускаем его как сервис systemd
sudo ./svc.sh install
sudo ./svc.sh start
На этом настройка runner закончена.
Подготовим данные для нашего приложения и разместим docker-compose файл
Отдельную папку создавать не будем, приложение будет запускаться из домашней папке пользователя (/home/app). Размещаем в папке файлы нужные для работы приложения. У меня это файл .env с переменными среды и папка data в которой хранится БД.
Создаем файл docker-compose.yml в домашней папке:
app:
image: ghcr.io/<имя репо>:<имя ветки>
env_file:
- .env
ports:
- "80:1323"
volumes:
- ./data:/data
Где <имя репо>:<имя ветки> это данные вашего репозитория, например itmind/testdeploy:main
Образ будет скачан с нашего приватного контейнера GitHub Packages, в который запишется в процессе CI/DI. У GitHub в базовую бесплатную подписку входит определенное количество минут и объема пространства которого достаточно, что бы каждый месяц не платить.
Создаем GitHub Actions workflow
Создать можно как интерактивно, через web-интерфейс, так и просто создав файл локально в папке проекта по пути .github/workflows. Сделаем там файл go.yml следующего содержания:
name: Go
on:
push:
branches: [ "main" ]
env:
REGISTRY: ghcr.io
IMAGE_NAME: ${{ github.repository }}
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- name: Set up Go
uses: actions/setup-go@v4
with:
go-version: 'stable'
- name: Build
run: go build -v ./...
- name: Test
run: go test -v ./...
build-and-push-image:
needs: build
runs-on: ubuntu-latest
permissions:
contents: read
packages: write
steps:
- name: Log in to the Container registry
uses: docker/login-action@v2
with:
registry: ${{ env.REGISTRY }}
username: ${{ github.actor }}
password: ${{ secrets.GITHUB_TOKEN }}
- name: Extract metadata (tags, labels) for Docker
id: meta
uses: docker/metadata-action@v4
with:
images: ${{ env.REGISTRY }}/${{ env.IMAGE_NAME }}
- name: Set up Docker Buildx
uses: docker/setup-buildx-action@v2
- name: Build and push Docker image
uses: docker/build-push-action@v4
with:
push: true
tags: ${{ steps.meta.outputs.tags }}
labels: ${{ steps.meta.outputs.labels }}
cache-from: type=gha
cache-to: type=gha,mode=max
deploy:
runs-on: self-hosted
needs: build-and-push-image
steps:
- name: Log in to the Container registry
uses: docker/login-action@65b78e6e13532edd9afa3aa52ac7964289d1a9c1
with:
registry: ${{ env.REGISTRY }}
username: ${{ github.actor }}
password: ${{ secrets.GITHUB_TOKEN }}
- name: Run container
run: |
cd ~
docker-compose up --build --pull=always &
Наш workflow состоит за 3 задач и запускается при пуше в ветку main.
- Собираем приложение go и запускаем тесты в образе ubuntu
- Если сборка и тесты прошли, то собираем образ по Dockerfile (ниже опишу) и отправляем его в репозиторий GitHub Packages
- На нашем сервера, через наш runner, выполняем команду в домашней папке. Ключ –build нужен, что бы образ всегда скачивался заново.
Теперь при пуше в ветку main на GitHub через несколько минут обновится приложение на сервере. В версии actions/setup-go@v4 кэш включен, поэтому при повторной сборке зависимости заново скачиваться не будут. Так же включен кэш для слоев образа докера.
Файл Dockerfile в корне проекта
FROM golang:alpine AS builder
ENV CGO_ENABLED 1
RUN apk update && apk add --no-cache git ca-certificates tzdata upx && update-ca-certificates
#Установка gcc и библиотек для разработки
RUN apk add --update alpine-sdk
WORKDIR /build
ADD go.mod .
ADD go.sum .
RUN go mod download
COPY . .
RUN CGO_ENABLED=1 GOARCH=amd64 GOOS=linux go build -ldflags "-s -w -extldflags '-static'" -o app
# Сжатие исполняемого файла
RUN upx ./hds
FROM scratch
COPY --from=builder /etc/ssl/certs/ca-certificates.crt /etc/ssl/certs/
COPY --from=builder /usr/share/zoneinfo /usr/share/zoneinfo/
COPY --from=builder /build/app /app
CMD ["/app"]
Multistage сборка. Сначала компилируем приложение в одном образе, затем передаем его в другой образ.
Параметры -ldflags “-s -w -extldflags ‘-static'” нуны что бы исключить всю отладочную информацию и включить в исполняемый файл зависимые библиотеки. К сожалению libc6 не линкуется статически Если не включить зависимые библиотеки (libc6), то например собрав приложение в Ubuntu 22.04 оно не запустится на Ubuntu 20.04, т.к. там другая версия libc6.
Так же в итоговый образ включены корневые сертификаты для использования SSL (HTTPS)
Продолжение смотрите здесь