ArgoCD — это декларативный инструмент непрерывной доставки GitOps для Kubernetes. Т.е дает возможность выполнять деплой приложений в K8S и хранить все конфиги в гите.

Установка ArgoCD в Unix/Linux

Для начало что необходимо, так установить Кубернетес, у меня есть ряд статей на эту тему:

Установка Kubernetes кластера в Unix/Linux

Установка Kubernetes в Unix/Linux

Команды Kubernetes в Unix/Linux

Создание AWS EKS кластера в Unix/Linux

Установка minikube в Unix/Linux

После чего, создаем неймспейс:

$ kubectl create namespace argocd

Установка ArgoCD через KubeCTL

Первое что необходимо, так — это поставить данную утилиту под названием kubectl!

Выполняем деплой:

$ kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml

Можно выполнить установку еще так (Non-HA):

$ export VESION=$(curl --silent "https://api.github.com/repos/argoproj/argo-cd/releases/latest" | grep '"tag_name"' | sed -E 's/.*"([^"]+)".*/\1/')
$ export ARGO_VERSION="v1.8.0-rc1"
$ kubectl apply -n argo -f https://raw.githubusercontent.com/argoproj/argo/${ARGO_VERSION}/manifests/install.yaml

Можно выполнить установку еще так (HA):

$ export ARGO_VERSION="v1.8.0-rc1"
$ kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/${ARGO_VERSION}/manifests/ha/install.yaml

Установка ArgoCD через Helm

Первое что необходимо, так — это поставить данную утилиту под названием helm!

И выполняем deploy:

$ helm repo add argo https://argoproj.github.io/argo-helm

$ helm install argocd \
	-n argocd \
	--set global.image.repository="argoproj/argocd" \
	--set global.image.tag="v1.8.1" \
	--set server.service.type="LoadBalancer" \
	argo/argo-cd

Если используете локальный миникуб или что-то такое, то запускаем так:

helm install argocd \
	-n argocd \
	--set global.image.repository="argoproj/argocd" \
	--set global.image.tag="v1.8.1" \
	argo/argo-cd

Проверим что все подымается так:

$ kubectl get po -n argocd && \
kubectl get service -n argocd

Можем идти дальше.

Кстати, пароль будет таким:

$ export OLD_ARGOCD_PWD=$(kubectl get pods -n argocd -l app.kubernetes.io/name=argocd-server -o name | cut -d'/' -f 2)

Если что, его можно поменять.

Установка ArgoCD через Terraform

Я недавно писал модуль для работы с helm, и на примере ArgoCD выполнил деплой. Код выглядит так:

#
# MAINTAINER Vitaliy Natarov "vitaliy.natarov@yahoo.com"
#
terraform {
  required_version = "~> 0.13"
}

module "helm_release" {
  source = "../../modules/release"

  enable_release     = true
  release_name       = "argocd-dev"
  release_chart      = "argo-cd"
  release_repository = "https://argoproj.github.io/argo-helm"
  release_version    = "v1.7.6"

  release_namespace        = "argocd-dev"
  release_create_namespace = true
  release_values           = []

  release_set = [
    {
      name  = "server.service.type"
      value = "LoadBalancer"
    }
  ]
  release_set_sensitive = []
  release_postrender    = []

  release_timeout       = 600
  release_force_update  = false
  release_recreate_pods = true
  release_lint          = false

}

Код с моими модулями можно найти тут — https://github.com/SebastianUA/terraform/blob/master/helm/examples/release/main.tf

Попозже дополню данную статью этим материалом.

Настройка ArgoCD в Unix/Linux

Поле того, как у вас задеплоится ArgoCD, вы не можете знать пароль от стандартного пользователя (admin), но его можно посмотреть тут:

$ kubectl get secret -n argocd argocd-secret -o yaml

Или, так:

$ kubectl get secret -n argocd argocd-secret -o yaml | grep -Ei "  admin.password: "

Т.к кубернетес пишет все секреты в base64, то декодировать строку можно так:

$ kubectl get secret -n argocd argocd-secret -o yaml | grep -Ei "  admin.password: " | awk '{print $2}' | base64 --decode

Пока не понял как расшифровать пароль с BCrypt. По этому, пойду по простому пути, а именно — перепишу пароль на нужный, например, вы хотите поставить пароль «admin» — т.е как и логин. Дано:

• Plain Text: admin
• BCrypt Hash:

$2b$10$ixLkbNDoNmoo3sHorEFequhJeEsZBtFVGlYjEhKZqBv2dlgTmbt.G

И выполняем патч:

$ kubectl -n argocd patch secret argocd-secret \
  -p '{"stringData": {
    "admin.password": "$2b$10$ixLkbNDoNmoo3sHorEFequhJeEsZBtFVGlYjEhKZqBv2dlgTmbt.G",
    "admin.passwordMtime": "'$(date +%FT%T%Z)'"
  }}'

Можно использовать login & password — admin.

Можно, просто выключить авторизацию так:

$ kubectl patch deploy argocd-server -n argocd -p '[{"op": "add", "path": "/spec/template/spec/containers/0/command/-", "value": "--disable-auth"}]' --type json

Добавление пользователей в ArgoCD

Посмотреть конфиг с юзерами и паролями, можно так:

$ kubectl get secret -n argocd argocd-secret -o yaml

Первое что нужно — это отредактировать:

$ kubectl edit -n argocd configmap/argocd-cm

И приводим к виду:

data:
  accounts.vnatarov: apiKey, login
  accounts.vnatarov.enabled: "true"
  accounts.test: apiKey, login
  accounts.test.enabled: "true"

Где:

• vnatarov & test — это имена юзеров.
• apiKey — Позволяет генерировать токены.
• login — Позволяет выполнять вход в UI админку ArgoCD.
• enabled: «true» — Говорит системе то, что юзер будет включен.

Для пользователей я поставлю пароль по логину чтобы проверить как это будет работать.

Патчим пароли:

$ kubectl -n argocd patch secret argocd-secret \
  -p '{"stringData": {
    "vnatarov.password": "$2b$10$ySVNtxkJVrSmh2GQA2zTLOzNedw1QPtDMYXp0X21WYSFwqvVUdWfm",
    "vnatarov.passwordMtime": "'$(date +%FT%T%Z)'"
  }}'

kubectl -n argocd patch secret argocd-secret \
  -p '{"stringData": {
    "test.password": "$2b$10$O1Jc1FgWcDN.PC0mA6xdPOT4OmUQXHupcO9/0k6r6MHYLhuH7ALP6",
    "test.passwordMtime": "'$(date +%FT%T%Z)'"
  }}'

Или, можно отредактировать (но тогда нужно будет зашифровать фразу в base64):

$ kubectl edit secret -n argocd argocd-secret

Чет какие-то баги в аргоСД и я смог пофиксить способом что описал выше, по этому, выполнил вход в админку:

$ yes | argocd login 127.0.0.1:8080 --username admin --password admin

Можно поглядеть учетки:

$ argocd account list
NAME      ENABLED  CAPABILITIES
admin     true     login
test      true     login, apiKey
vnatarov  true     apiKey, login

Ну и обновляем пароль:

$ argocd account update-password --account test --new-password 'test'

Точно так же для моего другого юзера:

$ argocd account update-password --account vnatarov --new-password 'vnatarov'
*** Enter current password:
Password updated

Приведу полный вывод моего конфига configmap-ы argocd-cm:

$ kubectl get -n argocd configmap/argocd-cm -o yaml

apiVersion: v1
data:
  accounts.test: login,apiKey
  accounts.test.enabled: "true"
  accounts.vnatarov: apiKey,login
  accounts.vnatarov.enabled: "true"
  application.instanceLabelKey: argocd.argoproj.io/instance
  statusbadge.enabled: "true"
  url: https://127.0.0.1:8080
  users.anonymous.enabled: "true"
kind: ConfigMap
metadata:
  annotations:
    meta.helm.sh/release-name: argocd
    meta.helm.sh/release-namespace: argocd
  creationTimestamp: "2021-01-05T18:18:34Z"
  labels:
    app.kubernetes.io/component: server
    app.kubernetes.io/instance: argocd
    app.kubernetes.io/managed-by: Helm
    app.kubernetes.io/name: argocd-cm
    app.kubernetes.io/part-of: argocd
    helm.sh/chart: argo-cd-2.11.0
  managedFields:
  - apiVersion: v1
    fieldsType: FieldsV1
    fieldsV1:
      f:data:
        .: {}
        f:application.instanceLabelKey: {}
      f:metadata:
        f:annotations:
          .: {}
          f:meta.helm.sh/release-name: {}
          f:meta.helm.sh/release-namespace: {}
        f:labels:
          .: {}
          f:app.kubernetes.io/component: {}
          f:app.kubernetes.io/instance: {}
          f:app.kubernetes.io/managed-by: {}
          f:app.kubernetes.io/name: {}
          f:app.kubernetes.io/part-of: {}
          f:helm.sh/chart: {}
    manager: Go-http-client
    operation: Update
    time: "2021-01-05T18:18:34Z"
  - apiVersion: v1
    fieldsType: FieldsV1
    fieldsV1:
      f:data:
        f:accounts.test.enabled: {}
        f:accounts.vnatarov.enabled: {}
        f:statusbadge.enabled: {}
        f:url: {}
        f:users.anonymous.enabled: {}
    manager: kubectl-edit
    operation: Update
    time: "2021-01-05T21:18:04Z"
  - apiVersion: v1
    fieldsType: FieldsV1
    fieldsV1:
      f:data:
        f:accounts.test: {}
        f:accounts.vnatarov: {}
    manager: argocd-server
    operation: Update
    time: "2021-01-05T21:32:26Z"
  name: argocd-cm
  namespace: argocd
  resourceVersion: "122982"
  selfLink: /api/v1/namespaces/argocd/configmaps/argocd-cm
  uid: adc7f9e5-1318-44c7-a59e-ba1625a8f887

Приведу полный вывод моего конфига secret-а argocd-secret:

$ kubectl get secret -n argocd argocd-secret -o yaml

apiVersion: v1
data:
  accounts.test.password: JDJhJDEwJEhyUW0uQlo2alFTRWxvT1J3N3BKMnVXOGVGLnVRUGc4cC5LQ2JSTGJqUzRtYWtWVDRZZ1dl
  accounts.test.passwordMtime: MjAyMS0wMS0wNVQyMToyNzo0NFo=
  accounts.test.tokens: bnVsbA==
  accounts.vnatarov.password: JDJhJDEwJGExRElNNnk5SFhqM1h3ZmZjMkFNa094eGdROUYzTTg0OUQ2M1BoOFhnZXB3VkNrc2ZoZnYy
  accounts.vnatarov.passwordMtime: MjAyMS0wMS0wNVQyMTozMjoyNlo=
  accounts.vnatarov.tokens: bnVsbA==
  admin.password: JDJiJDEwJGl4TGtiTkRvTm1vbzNzSG9yRUZlcXVoSmVFc1pCdEZWR2xZakVoS1pxQnYyZGxnVG1idC5H
  admin.passwordMtime: MjAyMS0wMS0wNVQyMDoyMTowNFo=
  server.secretkey: MDZ5QVA3WVZ4cTQ0ZDFDdXZzaEZqZjcydDZmUmVmdjQ0UXFsenhUWDZEcz0=
  test.password: JDJiJDEwJE8xSmMxRmdXY0ROLlBDMG1BNnhkUE9UNE9tVVFYSHVwY085LzBrNnI2TUhZTGh1SDdBTFA2
  test.passwordMtime: MjAyMS0wMS0wNVQyMjo0NTozNEVFVA==
  tls.crt: YYYYY=
  tls.key: XXXXXXX==
  vnatarov.password: JDJiJDEwJHlTVk50eGtKVnJTbWgyR1FBMnpUTE96TmVkdzFRUHRETVlYcDBYMjFXWVNGd3F2VlVkV2Zt
  vnatarov.passwordMtime: MjAyMS0wMS0wNVQyMjoyNjo0N0VFVA==
kind: Secret
metadata:
  annotations:
    meta.helm.sh/release-name: argocd
    meta.helm.sh/release-namespace: argocd
  creationTimestamp: "2021-01-05T18:18:34Z"
  labels:
    app.kubernetes.io/component: server
    app.kubernetes.io/instance: argocd
    app.kubernetes.io/managed-by: Helm
    app.kubernetes.io/name: argocd-secret
    app.kubernetes.io/part-of: argocd
    helm.sh/chart: argo-cd-2.11.0
  managedFields:
  - apiVersion: v1
    fieldsType: FieldsV1
    fieldsV1:
      f:metadata:
        f:annotations:
          .: {}
          f:meta.helm.sh/release-name: {}
          f:meta.helm.sh/release-namespace: {}
        f:labels:
          .: {}
          f:app.kubernetes.io/component: {}
          f:app.kubernetes.io/instance: {}
          f:app.kubernetes.io/managed-by: {}
          f:app.kubernetes.io/name: {}
          f:app.kubernetes.io/part-of: {}
          f:helm.sh/chart: {}
      f:type: {}
    manager: Go-http-client
    operation: Update
    time: "2021-01-05T18:18:34Z"
  - apiVersion: v1
    fieldsType: FieldsV1
    fieldsV1:
      f:data:
        f:admin.password: {}
        f:test.password: {}
        f:test.passwordMtime: {}
        f:vnatarov.password: {}
        f:vnatarov.passwordMtime: {}
    manager: kubectl-patch
    operation: Update
    time: "2021-01-05T20:45:35Z"
  - apiVersion: v1
    fieldsType: FieldsV1
    fieldsV1:
      f:data:
        .: {}
        f:accounts.test.password: {}
        f:accounts.test.passwordMtime: {}
        f:accounts.test.tokens: {}
        f:accounts.vnatarov.password: {}
        f:accounts.vnatarov.passwordMtime: {}
        f:accounts.vnatarov.tokens: {}
        f:admin.passwordMtime: {}
        f:server.secretkey: {}
        f:tls.crt: {}
        f:tls.key: {}
    manager: argocd-server
    operation: Update
    time: "2021-01-05T21:32:26Z"
  name: argocd-secret
  namespace: argocd
  resourceVersion: "122983"
  selfLink: /api/v1/namespaces/argocd/secrets/argocd-secret
  uid: 17e9ff5c-946d-4655-bd05-c983091ef210
type: Opaque

Приведу полный вывод моего конфига secret-а argocd-secret:

$ kubectl get -n argocd configmap/argocd-rbac-cm -o yaml

apiVersion: v1
data:
  policy.csv: |
    # Built-in policy which defines two roles: role:readonly and role:admin,
    # and additionally assigns the admin user to the role:admin role.
    # There are two policy formats:
    # 1. Applications (which belong to a project):
    # p, <user/group>, <resource>, <action>, <project>/<object>
    # 2. All other resources:
    # p, <user/group>, <resource>, <action>, <object>

    p, role:readonly, applications, get, */*, allow
    p, role:readonly, certificates, get, *, allow
    p, role:readonly, clusters, get, *, allow
    p, role:readonly, repositories, get, *, allow
    p, role:readonly, projects, get, *, allow
    p, role:readonly, accounts, get, *, allow
    p, role:readonly, gpgkeys, get, *, allow

    p, role:admin, applications, create, */*, allow
    p, role:admin, applications, update, */*, allow
    p, role:admin, applications, delete, */*, allow
    p, role:admin, applications, sync, */*, allow
    p, role:admin, applications, override, */*, allow
    p, role:admin, applications, action/*, */*, allow
    p, role:admin, certificates, create, *, allow
    p, role:admin, certificates, update, *, allow
    p, role:admin, certificates, delete, *, allow
    p, role:admin, clusters, create, *, allow
    p, role:admin, clusters, update, *, allow
    p, role:admin, clusters, delete, *, allow
    p, role:admin, repositories, create, *, allow
    p, role:admin, repositories, update, *, allow
    p, role:admin, repositories, delete, *, allow
    p, role:admin, projects, create, *, allow
    p, role:admin, projects, update, *, allow
    p, role:admin, projects, delete, *, allow
    p, role:admin, accounts, update, *, allow
    p, role:admin, gpgkeys, create, *, allow
    p, role:admin, gpgkeys, delete, *, allow

    g, role:admin, role:readonly
    g, admin, role:admin
    g, vnatarov, role:admin
  policy.default: role:readonly
kind: ConfigMap
metadata:
  annotations:
    meta.helm.sh/release-name: argocd
    meta.helm.sh/release-namespace: argocd
  creationTimestamp: "2021-01-05T18:18:34Z"
  labels:
    app.kubernetes.io/component: server
    app.kubernetes.io/instance: argocd
    app.kubernetes.io/managed-by: Helm
    app.kubernetes.io/name: argocd-rbac-cm
    app.kubernetes.io/part-of: argocd
    helm.sh/chart: argo-cd-2.11.0
  managedFields:
  - apiVersion: v1
    fieldsType: FieldsV1
    fieldsV1:
      f:metadata:
        f:annotations:
          .: {}
          f:meta.helm.sh/release-name: {}
          f:meta.helm.sh/release-namespace: {}
        f:labels:
          .: {}
          f:app.kubernetes.io/component: {}
          f:app.kubernetes.io/instance: {}
          f:app.kubernetes.io/managed-by: {}
          f:app.kubernetes.io/name: {}
          f:app.kubernetes.io/part-of: {}
          f:helm.sh/chart: {}
    manager: Go-http-client
    operation: Update
    time: "2021-01-05T18:18:34Z"
  - apiVersion: v1
    fieldsType: FieldsV1
    fieldsV1:
      f:data:
        .: {}
        f:policy.csv: {}
        f:policy.default: {}
    manager: kubectl-edit
    operation: Update
    time: "2021-01-05T20:34:00Z"
  name: argocd-rbac-cm
  namespace: argocd
  resourceVersion: "116734"
  selfLink: /api/v1/namespaces/argocd/configmaps/argocd-rbac-cm
  uid: aa1649df-d477-4258-bb3a-f7219326ad84

Можно юзать!

Убрать HTTPS в ArgoCD

Патчим:

$ kubectl patch deploy argocd-server -n argocd -p '[{"op": "add", "path": "/spec/template/spec/containers/0/command/-", "value": "--insecure"}]' --type json

И потом все норм.

Создание RBAC для пользователей

Команда простая (на примере дефолтного админа):

$ kubectl -n argocd create rolebinding default-admin --clusterrole=admin --serviceaccount=argo:default

Дальше — больше.

Создание ArtifactRepository для ArgoCD

Создаем это так:

$ cat <<EoF > argo-patch.yaml
data:
  config: |
    artifactRepository:
      s3:
        endpoint: s3.amazonaws.com
        bucket: batch-artifact-repository
EoF

Где:

• batch-artifact-repository — это созданный бакет.

И применяем:

$ kubectl -n argocd patch \
  configmap/argocd-cm \
  --patch "$(cat argo-patch.yaml)"

Вот так вот.

Установка оператора (Argo CD Operator) для ArgoCD (Helm)

Установка очень простая:

$ kubectl apply -f https://operatorhub.io/install/argocd-operator-helm.yaml

После чего, проверяем:

$ kubectl get csv -n my-argocd-operator-helm

Или, еще проще способ:

$ curl -sL https://github.com/operator-framework/operator-lifecycle-manager/releases/download/v0.17.0/install.sh | bash -s v0.17.0

После чего, проверяем:

$ kubectl get csv -n olm

Вот и все.

Использование ArgoCD в Unix/Linux

Пропишу команду для дальнейшего использования:

$ export ARGOCD_SERVER=$(kubectl get pods -n argocd -l app.kubernetes.io/name=argocd-server -o name | cut -d'/' -f 2)

Т.к я выбрал локальный запуск и приложение не смотрит в мир, то нужно выполнить форвардинг порта:

$ kubectl port-forward service/argocd-server -n argocd 8080:443

И после данного действия, у вас будет работать argoCD на 127.0.0.1:8080

Т.к я использую макбук, то следующая команда установит argocd CLI на мой мак:

$ brew install argocd

Далее, выполним логин:

$ argocd login localhost:8080 --insecure --username admin --grpc-web

NOTE: Нужно знать пароль!

Далее, ставим 1-е приложение:

$ argocd app create guestbook \
--repo https://github.com/pcrete/argocd-example-apps.git \
--path guestbook \
--dest-server https://kubernetes.default.svc \
--dest-namespace guestbook

И далее, ставим 2-е приложение:

$ argocd app create webapp \
--repo https://gitlab.com/gitops-argocd-demo/webapp-chart.git \
--path . \
--dest-server https://kubernetes.default.svc \
--dest-namespace hello-gitops \
--sync-policy automated \
--auto-prune \
--self-heal

Можно открыть в браузере аргоСД и поглядеть что оно будет делать.

Вот и все, статья «Установка ArgoCD в Unix/Linux» завершена.

Недавно, в GitHub появилась возможность использовать workflows для различных задач. Например, можно сделать флов для проверки вашего кода перед тем как код будет смерджен в какую-то из бранчей ( например — master). Я приведу пример использования lint для Terrafrom-а, т.е я хочу чтобы код работал не только у меня локально, но и после того как я его запушу в репозиторий — он будет проходить проверку и даст мне знать если что-то пойдет не так.

Структура моего .github фолдера выглядит так:

$ tree .github | grep -Ev "_BK"
.github
|-- FUNDING.yml
|-- ISSUE_TEMPLATE
|   |-- bug_report.md
|   |-- custom.md
|   `-- feature_request.md
|-- actions
|-- lock.yml
|-- move.yml
|-- no-response.yml
|-- stale.yml
`-- workflows
    |-- terraform-lint.yaml

3 directories, 11 files

Где:

• FUNDING.yml — Служит файлом для настройки донатинга проекта. Добавил чтобы было…
• actions — Папка для yaml-файлов с конфигурацией действий для workflows. Т.е описываем что можно выполнять и каким образом. У меня в данном случае — папка пуска и я использую только workflows с готовым примером.
• workflows — Это папка в которой лежат yaml-файлы с ворк-фловами, т.е файлами конфигураций при работе с вашим проектом. Например, проверка орфограции, выполнение init & plan & apply для Terrafrom-а ( в моем случае). Т.е я хочу сказать — это что-то типа CI/CD в GitHub и похожу что Микромелкие сперли некоторые из фичей с GitLab CI.

Создаем GitHub workflows с actions для Terraform в Unix/Linux

GitHub Actions позволяют создавать собственные рабочие процессы жизненного цикла разработки программного обеспечения (SDLC) непосредственно в вашем репозитории GitHub.

Мой самый простой lint для Terraform выглядит:

$ cat .github/workflows/terraform-lint.yaml
---
name: terraform-lint

on: [push, pull_request]

jobs:
  delivery:
    runs-on: ubuntu-latest
    steps:
      - name: Check out code
        uses: actions/checkout@master
      - name: Lint Terraform
        uses: actionshub/terraform-lint@master

Я не создавал экшены и взял готовое использование проекта ( написанного кем-то до меня).

Еще, имеется и другой пример использование:

---
name: 'Terraform GitHub Actions'

# on: 
#   pull_request:
#     branches:
#       - master

on:
  - pull_request

jobs:
  terraform:
    name: 'Terraform'
    runs-on: ubuntu-latest
    steps:
      - name: 'Check out code'
        uses: actions/checkout@master
      - name: 'Terraform Format'
        uses: hashicorp/terraform-github-actions@master
        with:
          tf_actions_version: 0.12.13
          tf_actions_subcommand: 'fmt'
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
      - name: 'Terraform Init'
        uses: hashicorp/terraform-github-actions@master
        with:
          tf_actions_version: 0.12.13
          tf_actions_subcommand: 'init'
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
          TF_ACTION_WORKING_DIR: '.'
          AWS_ACCESS_KEY_ID:  ${{ secrets.AWS_ACCESS_KEY_ID }}
          AWS_SECRET_ACCESS_KEY:  ${{ secrets.AWS_SECRET_ACCESS_KEY }}
      - name: 'Terraform Validate'
        uses: hashicorp/terraform-github-actions@master
        with:
          tf_actions_version: 0.12.13
          tf_actions_subcommand: 'validate'
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
      - name: 'Terraform Plan'
        uses: hashicorp/terraform-github-actions@master
        with:
          tf_actions_version: 0.12.13
          tf_actions_subcommand: 'plan'
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
          AWS_ACCESS_KEY_ID:  ${{ secrets.AWS_ACCESS_KEY_ID }}
          AWS_SECRET_ACCESS_KEY:  ${{ secrets.AWS_SECRET_ACCESS_KEY }}

ЗАМЕЧАНИЕ: В данном примере — использую secrets, которые нужно прописать в настройках самого проекта. Данную настройку можно найти по следующему пути:

<GITHUB_URL>/<YOUR_USER>/<YOUR_REPO_NAME>/settings/secrets

Где:

• <GITHUB_URL> — URL от гитхаба (с http или https).
• <YOUR_USER> — Юзер от которого запушился код.
• <YOUR_REPO_NAME> — Репозиторий.

Например у меня это выглядит так:

https://github.com/SebastianUA/terraform/settings/secrets

Нашел в интернете «runatlantis» проект который позволяет выполнять действия (terraform plan, terraform apply — это как пример) написав команду в комментарии ( например pull request-а). Не проверял работу, но оставил чтобы не забыть про него, если нужно будет заюзать.

Вот и все, статья «Создаем GitHub workflows с actions в Unix/Linux» завершена.

При использовании слейвов в дженкинсе, всегда есть вероятность что какая-то из нод, — отпадет из-за какой-то из причин (Например: проблемы с сетью; закрылся порт). А если это ПРОД сервер и там должны собираться проекты. То за некоторый промежуток времени у вас может собраться большое количество выключенных машин.

Полезное чтиво:

Установка Jenkins и Jenkins-slave в Unix/Linux

Автосборка Java проектов через Jenkins в Unix/Linux

Настройка языка в Jenkins

Разграничение прав доступа в Jenkins

Мониторинг места на сервере через Jenkins

Настройка темы для Jenkins

Изменить/Поменять пароль для пользователя Jenkins

Создание Jenkins backup/restore в Unix/Linux

Автосборка Java проектов через Jenkins в Unix/Linux

Я нашел пару решений как это можно сделать. Покажу на наглядных примера как мне удалось убить больше 1.5к зомби-нод.

Удалить все Jenkins offline nodes

Так, одним из способов удалить все офлайн-хосты — это выполнить груви-скрипт через дженкинс консоль. Для этого, нужно зологиниться в сам дженкинс, затем кликнуть по «Manage Jenkins» и перейти в «script Console»:

В само поле со скриптом, вставить:

Closure query = { it.name ==~ /^.*$/  }
Closure action = {
  println('====================')
  println("Name: ${it.name}")
  println("LabelString: ${it.labelString}")
  println("NumExectutors: ${it.numExecutors}")
  println("RemoteFS: ${it.remoteFS}")
  println("Mode: ${it.mode}")
  println("RootPath: ${it.rootPath}")
  println("Offline: ${it.computer.offline}")
  
  if (it.computer.offline) {
    println("Deleting node: ${it.name}")
    it.computer.doDoDelete()
  }
}

Jenkins.instance.slaves.findAll(query).each(action)
return

Нажимаем на «RUN» и если много хостов, — это занимает некоторое время. Данный пример — полностью использовался на ПРОД серверах компании где работаю.

Удалить все Jenkins offline slaves

Проверил другой подход скрипта на груви. Полностью рабочий вариант. Чтобы удалить все офлайн-слейвы, нужно зологиниться в сам дженкинс, затем кликнуть по «Manage Jenkins» и перейти в «script Console»:

В само поле со скриптом, вставить:

for (aSlave in hudson.model.Hudson.instance.slaves) {
    if (aSlave.getComputer().isOffline()) {
        aSlave.getComputer().setTemporarilyOffline(true,null);
        aSlave.getComputer().doDoDelete();
    }
}

Нажимаем на «RUN» и если много хостов, — это занимает некоторое время. Данный пример — полностью использовался на ПРОД серверах компании где работаю.

Мне данные решения помогли и они полностью рабочие. Еси будут еще идеи чем можно дополнить — обязательно дополню данную тему.

Вот и все, статья «Удалить все Jenkins offline nodes/slaves в Unix/Linux» завершена.

Spinnaker — это платформа для создание пайплайнов непрерывного деплоймента, позволяющая быстро и уверенно сообщать об изменениях. Данное ПО разрабатывала Netflix, потом начала поддерживать и Google. Служит для деплоя приложений в Kubernetes (k8s) автоматическим способом.

Архитектура выглядит следующим образом:

Компоненты Spinnaker-а:

• Deck: Один из микросервисов, который лужит веб UI интерфесом, для конйигурации Spinnaker через веб-браузер. Так же, просмотр приложений и проектов, пайплайнов.
• Gate: Один из микросервисов, который лужит API сервисом и пользовательский интерфейс Spinnaker, который взаимодействуют с сервером Spinnaker через этот API-шлюз, который называется Gate.
• Orca: Один из микросервисов, который служит для управления пайплайнами и другими специальными операциями через данный оркестровщик, называемый Orca.
• Clouddriver: Один из микросервисов, который служит для индексации и кэшировании развернутых ресурсов. Так же, взаимодействует с таким облачным провайдерам, как AWS, GCE и Azure.
• Echo: Один из микросервисов, который отвечает за отправку уведомлений, а также выступает в качестве входящего webhook-а.
• Igor: Один из микросервисов, используется для запуска конвейеров (pipelines) с помощью заданий непрерывной интеграции в таких системах, как Jenkins и Travis CI, и позволяет использовать Jenkins / Travis stag-ы в пайплайнах.
• Front50: Один из микросервисов, который служит хранилищем метаданных в Spinnaker. Он сохраняет метаданные для всех ресурсов, включая пайплайны, проекты, приложения и уведомления.
• Rosco: Один из микросервисов, который служит для создания (аббревиатура bakes в спиннакере) образов машин (AWS AMIs, Azure VM images, GCE images).
• Rush: Один из микросервисов, служит для выполнения скриптов.

Перейдем к установке.

Установка Spinnaker в Unix/Linux

Есть довольно много способов как установить спинакер на различные ОС. Приведу наглядные примеры как это можно сделать.

Способы установки Spinnaker в Unix/Linux:

• Использовать Minio (при использовании Minikube или Docker Desktop).
• Использовать AWS S3 (при использовании Minikube или Docker Desktop).
• Использовать харнилище от GCP (при использовании Minikube или Docker Desktop). Пока не будет примеров.
• Azure сторедж (при использовании Minikube или Docker Desktop).
• Redis (при использовании Minikube или Docker Desktop). Пока не будет примеров.
• Так же, можно будет установить Spinnaker используя AWS EKS. Пока не будет примеров.
• Можно будет установить Spinnaker используя GCP GKE. Пока не будет примеров.

Установка spinnaker используя Docker Desktop в Unix/Linux

У меня МакОС и я буду использовать Docker Desktop. У меня он уже установлен, по этому — начнем.

Способы установки описанные в данном пункте:

• Использовать Minio.
• Использовать AWS S3.

Потребуется настроить докер на использование следующих ресурсов:

• 4Gb Оперативной памяти. Я ипользую 9Гб.
• 2Gb swap (подкачки). Я ипользую 4Гб.
• 4 CPU ядер. Я ипользую 6 ядер.

Настраиваем и перезапускаем докер.

Устанавливаем Halyard:

# cd /usr/local/src && $ curl -O https://raw.githubusercontent.com/spinnaker/halyard/master/install/macos/InstallHalyard.sh

Выполним установку:

$ sudo bash ./InstallHalyard.sh -y --user $USER

Проверим версию:

$ hal -v
1.21.1-20190624135101

Или, можно просмотреть список доступных версий:

$ hal version list

Чтобы использовать другую версию, выполните:

$ hal config version edit --version 1.12.13

Где:

• 1.12.13 — Это версия ПО.

Можно его установить с помощью Docker-а, но мне это не нужно было.

Выполним установку некоторых тулов:

$ brew install kubectl kubernetes-helm 

PS: Если не установлен homebrew, установка тут.

Переключимся на нужный контекст:

$ kubectl config use-context docker-for-desktop

Разрешаем кубернетис:

$ helm init --wait

Проверяем, работает ли kubernetes провайдер:

$ hal config provider kubernetes enable

Установим контекст и имя аккаунта:

$ export CONTEXT=$(kubectl config current-context) 
$ export ACCOUNT=my-k8s-v2-account

Добавляем аккаунт:

$ hal config provider kubernetes account add $ACCOUNT \
   --provider-version v2 \
   --context $CONTEXT

Выставляем конфиг-опции:

$ hal config features edit --artifacts true

Spinnaker развертывается в локальном кластере Kubernetes, причем каждый микросервис развертывается независимо. Halyard выполняем установку Spinnaker и его микросервисов, обеспечивая нулевое время простоя обновления.

Установим параметры ENV:

$ hal config deploy edit --type distributed --account-name $ACCOUNT

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

-=== Используем Minio ===-

Для Spinnaker требуется внешнее хранилище для сохранения настроек вашего приложения и настроенных пайплайнов — в качестве примера, развернем Minio S3 в отдельном Kubernetes контексте.

Minio — это S3-совместимое хранилище объектов, которое вы можете установить самостоятельно (селф-хостед).

Пробросим необходимые переменые:

$ export MINIO_ACCESS_KEY="VHK5D359RAXHEXAMPLE" && \
export MINIO_SECRET_KEY="vE8qPsiWjluG2mZRD1WHZANzSYW8X8C3BExAmPLe" && \
export MINIO_STORAGE_NAME="local-s3-storage" 

Запускаем minio:

$ helm install \
	--set persistence.size=8Gi \
	--set accessKey=$MINIO_ACCESS_KEY,secretKey=$MINIO_SECRET_KEY \
	--name $MINIO_STORAGE_NAME \
	--namespace storage \
	stable/minio

Запускаем следующую команду:

$ kubectl get pods --namespace=storage -w

Ждем пока не будет «READY 1/1»

Нам будет нужна еще одна переменная:

$ export POD_NAME=$(kubectl get pods --namespace storage -l "release=`echo ${MINIO_STORAGE_NAME}`" -o jsonpath="{.items[0].metadata.name}")

Далее, запускаем прокси в бэкграунде:

$ nohup kubectl port-forward $POD_NAME 9001:9000 --namespace storage &

PS: Можем открыть http://localhost:9001 чтобы зайти в S3 хранилище.

Определим ендпоинт который будем юзать:

$ export ENDPOINT="http://${MINIO_STORAGE_NAME}.storage.svc.cluster.local:9000"

Так же, стоит выбрать имя для деплоймента:

$ export DEPLOYMENT=default

Создадим проект:

$ mkdir -p ~/.hal/$DEPLOYMENT/profiles

Установим опцию игнорирования версий S3:

$ echo "spinnaker.s3.versioning: false" > \
      ~/.hal/$DEPLOYMENT/profiles/front50-local.yml

Конфигурируем S3 сторедж ендпоинт и креденшелы для Halyard:

$ echo $MINIO_SECRET_KEY | hal config storage s3 edit \
	--endpoint $ENDPOINT \
	--access-key-id $MINIO_ACCESS_KEY \
	--secret-access-key # will be read on STDIN

Включаем созданный S3 сторедж:

$ hal config storage edit --type s3

Теперь, когда включили провайдер Kubernetes (Docker for Desktop), выбрали среду распределенного развертывания и настроили постоянное хранилище Minio S3, теперь необходимо выбрать версию Spinnaker, развернуть ее и подключиться к ней.

Выставляем версию для деплоймента Spinnaker:

$ export VERSION="1.14.7" && \
hal config version edit --version $VERSION

Выполняем деплоймент:

$ hal deploy apply

Для проверки состояний, можно использовать:

$ kubectl get pods --namespace=spinnaker -w

Выполняем форвардинг портов 9000 (Deck UI) и 8084 (Gate API service):

$ hal deploy connect

-=== Используем AWS S3 ===-

Выполним:

$ export AWS_ACCESS_KEY="AWS_ACCESS_KEY"
$ export AWS_SECRET_KEY="AWS_SECRET_KEY"
$ export AWS_REGION="eu-north-1"
$ export AWS_S3_STORAGE_NAME="AWS_S3_STORAGE_NAME" 
$ export AWS_S3_ENDPOINT="https://${AWS_S3_STORAGE_NAME}.s3.amazonaws.com"
$ export DEPLOYMENT=default
$ mkdir -p ~/.hal/$DEPLOYMENT/profiles
$ echo "spinnaker.s3.versioning: false" > \
	~/.hal/$DEPLOYMENT/profiles/front50-local.yml
$ echo $AWS_SECRET_KEY | hal config storage s3 edit \
	--AWS_S3_ENDPOINT $AWS_S3_ENDPOINT \
	--access-key-id $AWS_ACCESS_KEY \
	--region $REGION \
	--secret-access-key # will be read on STDIN
$ hal config storage edit --type s3

Вот и все.

Удаление созданного барахла

Для удаления всего созданного, нужно выполнить ряд следующих команд.

Для начала, удаляем все деплойменты от спинакера:

$ hal deploy clean

Выполним команду для проверки:

$ kubectl get pods --namespace=spinnaker -w

Удалим неймспейс:

$ kubectl delete namespace spinnaker

Завершаем работу прокси от minio:

$ kill $(ps -ef | grep port-forward | grep my-s3-storage | awk '{ print $2 }')

Удаляем minio:

$ kubectl delete deployment ${MINIO_STORAGE_NAME} --namespace storage 
$ helm delete --purge ${MINIO_STORAGE_NAME}

Опять таки, можно выполнить команду для проверки:

$ kubectl get pods --namespace=storage -w

Удаляем неймспейс:

$ kubectl delete namespace storage

Еще, ели нужно удалить еще и Halyard, то выполняем:

$ kill $(ps -ef | grep com.netflix.spinnaker.halyard.Main | awk '{ print $2 }')
$ sudo ~/.hal/uninstall.sh

Удаление завершено.

Установка spinnaker используя Minikube в Unix/Linux

Устанавливаем Halyard:

# cd /usr/local/src && $ curl -O https://raw.githubusercontent.com/spinnaker/halyard/master/install/macos/InstallHalyard.sh

Выполним установку:

$ sudo bash ./InstallHalyard.sh -y --user $USER

Я буду использовать minikube для работы с k8s:

$ minikube start --cpus 4 --memory 8192

Поглядим под-ы:

$ kubectl get nodes

Выбираем контекст:

$ kubectl config use-context minikube

Иницилиализируемся:

$ helm init --wait

Включаем куб:

$ hal config provider kubernetes enable

Пробрасываем переменные:

$ export MINIO_ACCESS_KEY=VHK5D359RAXHEXAMPLE && \
  export MINIO_SECRET_KEY=vE8qPsiWjluG2mZRD1WHZANzSYW8X8C3BExAmPLe && \
  export ACCOUNT=demo-account

В отдельном окне терминала, запускаем минио:

$ docker run -p 9000:9000 --name minio1 \
  -e "MINIO_ACCESS_KEY=${MINIO_ACCESS_KEY}" \
  -e "MINIO_SECRET_KEY=${MINIO_SECRET_KEY}" \
  minio/minio server /data

ЗАМЕЧАНИЕ: можно еще добавить:

• -v /home/captain/minio/data:/data \
• -v /home/captain/minio/config:/root/.minio \

Но нужно их создать для начала (я за папки).

Добавляем минио к кубернетес:

$ echo ${MINIO_SECRET_KEY} | hal config storage s3 edit --endpoint http://localhost:9000     --access-key-id ${MINIO_ACCESS_KEY}     --secret-access-key
+ Get current deployment
  Success
+ Get persistent store
  Success
Generated bucket name: spin-ec1fb70b-43b4-4a05-88ab-868e8950637a
+ Edit persistent store
  Success
Problems in default.persistentStorage:
- WARNING Your deployment will most likely fail until you configure
  and enable a persistent store.

+ Successfully edited persistent store "s3".

И потом, еще одну команду:

$ hal config storage edit --type s3
+ Get current deployment
  Success
+ Get persistent storage settings
  Success
+ Edit persistent storage settings
  Success
+ Successfully edited persistent storage.

Для настройки Spinnaker kubernetes требуется как минимум Docker регистри. Добавляем регистри так:

hal config provider docker-registry account add dockerhub --address index.docker.io --repositories library/nginx

ЗАМЕЧАНИЕ: Можно использовать приватный докер регистри. Например, чтобы запустить локальный докер-регистри, можно выполнить:

$ docker run -d -p 5000:5000 --restart=always --name registry registry:2

Можете добавить приватный Docker регистр:

$ hal config provider docker-registry account add docker-private-repo --address https://localhost:5000 --username myuser  --password mypassword
+ Get current deployment
  Success
+ Add the docker-private-repo account
  Success
Problems in default.provider.dockerRegistry.docker-private-repo:
- WARNING Your docker registry has no repositories specified, and
  the registry's catalog is empty. Spinnaker will not be able to deploy any images
  until some are pushed to this registry.
? Manually specify some repositories for this docker registry to
  index.

+ Successfully added account docker-private-repo for provider
  dockerRegistry.

Разрешаем докер-регистри:

$ hal config provider docker-registry enable
+ Get current deployment
  Success
+ Edit the dockerRegistry provider
  Success
Problems in default.provider.dockerRegistry.docker-private-repo:
- WARNING Your docker registry has no repositories specified, and
  the registry's catalog is empty. Spinnaker will not be able to deploy any images
  until some are pushed to this registry.
? Manually specify some repositories for this docker registry to
  index.

+ Successfully enabled dockerRegistry

Добавляем аккаунт:

$ hal config provider kubernetes account add ${ACCOUNT} --kubeconfig-file=/Users/captain/.kube/config --docker-registries dockerhub --context $(kubectl config current-context)
+ Get current deployment
  Success
+ Add the demo-account account
  Success
+ Successfully added account demo-account for provider
  kubernetes.

Установим параметры ENV:

$ hal config deploy edit --type=distributed --account-name ${ACCOUNT}
+ Get current deployment
  Success
+ Get the deployment environment
  Success
+ Edit the deployment environment
  Success
+ Successfully updated your deployment environment.

Смотрим версии Spinnaker:

$ hal version list
+ Get current deployment
  Success
+ Get Spinnaker version
  Success
+ Get released versions
  Success
+ You are on version "", and the following are available:
 - 1.12.13 (Unbreakable):
   Changelog: https://gist.github.com/spinnaker-release/89e02b2d04aff5b5cab69c3963cbb157
   Published: Thu Jun 20 18:12:21 EEST 2019
   (Requires Halyard >= 1.11)
 - 1.13.10 (BirdBox):
   Changelog: https://gist.github.com/spinnaker-release/3056119e8dd52f5d24041fdf0a42fe3e
   Published: Thu Jun 20 18:31:31 EEST 2019
   (Requires Halyard >= 1.17)
 - 1.14.1 (LoveDeathAndRobots):
   Changelog: https://gist.github.com/spinnaker-release/4b4bb42d4e3b6073fbd5f89fa7c3e060
   Published: Fri May 24 18:17:14 EEST 2019
   (Requires Halyard >= 1.17)
 - 1.14.7 (LoveDeathAndRobots):
   Changelog: https://gist.github.com/spinnaker-release/cf6b8a7290ba0d9277360e7a794e0b6b
   Published: Mon Jun 24 17:03:24 EEST 2019
   (Requires Halyard >= 1.17)

Выбираем нужную и применяем настройку:

$ hal config version edit --version 1.14.7
+ Get current deployment
  Success
+ Edit Spinnaker version
  Success
+ Spinnaker has been configured to update/install version "1.14.7".
  Deploy this version of Spinnaker with `hal deploy apply`.

Деплоим:

$ hal deploy apply

Во время деплоймента, можно смотреть на создающиеся поды:

$ kubectl get pods --namespace spinnaker -w
NAME                                    READY   STATUS    RESTARTS   AGE
spin-clouddriver-bootstrap-v000-s2pnh   1/1     Running   0          105s
spin-clouddriver-v000-bs8gt             0/1     Running   0          26s
spin-deck-v000-hdwtg                    1/1     Running   0          26s
spin-echo-v000-8qnfr                    0/1     Running   0          26s
spin-front50-v000-7nxn6                 0/1     Running   0          26s
spin-gate-v000-qgq9w                    0/1     Running   0          26s
spin-igor-v000-bfpp4                    0/1     Running   0          25s
spin-orca-bootstrap-v000-swvpr          1/1     Running   0          69s
spin-orca-v000-njqz2                    0/1     Running   0          26s
spin-redis-bootstrap-v000-vkpx4         1/1     Running   0          110s
spin-redis-v000-rtbfj                   1/1     Running   0          37s
spin-rosco-v000-lwrc2                   0/1     Running   0          25s

Для запуска Spinnaker UI:

$ hal deploy connect

Если вы не хотите использовать hal для подключения, вы можете сделать переадресацию портов на модули Spinnaker:

alias spin_gate='kubectl port-forward -n spinnaker $(kubectl get pods -n spinnaker -o=custom-columns=NAME:.metadata.name | grep gate) 8084:8084'

alias spin_deck='kubectl port-forward -n spinnaker $(kubectl get pods -n spinnaker -o=custom-columns=NAME:.metadata.name | grep deck) 9001:9000'

alias spinnaker='spin_gate &; spin_deck &'

После чего, запускаем:

$ spinnaker
[1] 20836
[2] 20840

❯ Forwarding from 127.0.0.1:8084 -> 8084
Forwarding from [::1]:8084 -> 8084
Forwarding from 127.0.0.1:9001 -> 9000
Forwarding from [::1]:9001 -> 9000

Открываем http://localhost:9001

Готово!

Установка spinnaker используя Docker и Docker-Compose в Unix/Linux

Копируем код:

$ git clone https://github.com/spinnaker/spinnaker.git

Заходим в папку:

$ cd spinnaker/experimental/docker-compose/

Для удобства использования, я создам новую докер-машину:

$ docker-machine create spinnaker

Далее, выполняем:

$ export DOCKER_IP=$(docker-machine ip spinnaker) && \
docker-compose up -d

После деплоймента, можно выполнить:

$ open http://$(docker-machine ip spinnaker):9000

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

Установка spinnaker используя Kubernetes и Helm в Unix/Linux

Устанавливаем kubernetes (Docker for Desktop или Minikube, AWS EKS, GCP GKE etc).

Для данного примера, я возьму Docker for Desktop. Выполнил настройку как в примере выше.

Устанавливаем HELM:

Установка Helm в Unix/Linux

Затем, скачиваем чарт:

$ curl -Lo values.yaml https://raw.githubusercontent.com/kubernetes/charts/master/stable/spinnaker/values.yaml

Отредактируйте values.yaml, чтобы вставить учетные данные Docker Hub под учетной записью dockerhub. Добавьте репо, который вы открыли из моей учетной записи Github, в список репозиториев, например:

.........
dockerRegistries:
- name: dockerhub
  address: index.docker.io
  username: YOUR_USERNAME_HERE
  password: YOUR_PASSWORD_HERE
  repositories:
    - library/alpine
    - library/ubuntu
    - library/centos
    - library/nginx
.........

Где:

• YOUR_USERNAME_HERE — Пользователь от докер Хаба
• YOUR_PASSWORD_HERE — Пароль от пользователя от докер Хаба

У меня была ошибка с minio ПОД-ом, исправлением служило замена тега для образа minio, блок выглядит так:

.....
minio:
  enabled: true
  imageTag: latest
  serviceType: ClusterIP
  accessKey: spinnakeradmin
  secretKey: spinnakeradmin
  bucket: "spinnaker"
  pullPolicy: IfNotPresent
  nodeSelector: {}
.......

Теперь запустите Spinnaker с обновленной конфигурацией:

$ helm install -n kubelive stable/spinnaker -f values.yaml --timeout 300 --version 0.3.5 --namespace spinnaker

Откройте порт Spinnaker для хоста с помощью следующих команд:

$ export DECK_POD=$(kubectl get pods --namespace spinnaker -l "component=deck,app=kubelive-spinnaker" -o jsonpath="{.items[0].metadata.name}") && \
kubectl port-forward --namespace spinnaker $DECK_POD 9000

После этого, можно открыть Spinnaker из браузера, посетив http://localhost:9000

Как-то так.

Установка spinnaker используя AWS EKS в Unix/Linux

Пока не пробовал. Оставлю так, после дополню.

Установка spinnaker используя GCP GKE в Unix/Linux

Пока не пробовал. Оставлю так, после дополню.

Настройка/Использование Spinnaker в Unix/Linux

И так, настройка прошла успешно. Открыли Spinnaker на http://localhost:9000. Домашняя станица Spinnaker-а выглядит следующим образом:

В поле поиска, можно поискать проекты, кластера, ЛБ, секьюрити группы и тд и тп. Например:

Приступим к использованию!

Создание Spinnaker пайплайна

Начну создание приложения под названием MyTestApp:

Нажимаем на кнопку «Create». Созданное приложение выглядит так:

Идем далее, создаем лоад баллансер, для этого клацаем по «Load Balancers» -> «Create Load Balancer»:

Во вкладке с «BASIC SETTINGS», заполняем:

• Account -> local.
• Namespace -> default.
• Stack -> prod.

Далее, во вкладке с «PORTS»:

В данной вкладке стоит прописать:

• Target Port -> 80.

Далее, во вкладке с «ADVANCED SETTINGS»:

В данной вкладке, прописываем:

• Type -> NodePort.

Нажимаем на «Create». Аналогичными действиями, создаем ЛБ с названием «dev», но только в последней вкладке стоит выбрать «ClusterIP»:

После чего, должно выти что-то типа следующего:

ЛБы готовы и теперь можно создавать pipeline, переходим в данную вкладку и нажимаем на «Create»:

Заполняем:

• Pipeline Name -> DeployToProd

Нажимаем на «Create»:

Жмакаем на «Save Changes». Прокручиваем стрцницу вверх и кликаем на «Add stage»:

Заполняем:

• Stage name -> Deploy

Затем кликаем по «Add server group»:

Я выбрал:

• Copy configuration from -> None. Т.к у меня нет подходящих шаблонов для этого деплоймента.

Нажимаем на «Continue without a template»:

Нажимаем на вкладку «LOAD BALANCERS» и выбираем нужный (в данном случае — mytestapp-prod):

Переходим во «CONTAINER» вкладку и заполняем:

В данной вкладке, стоит открыть «Probes» и добавляем использование Readiness Probe и Liveness Probe:

И так, нажимаем на «Add» чтобы добавить наши ченджи. И потом, кликаем по «Save Changes».

Т.к я деплою nginx, а не приложение с кодом (так бы сработал триггер по коммиту), то запущу «Start manual execution»:

Выбераем параметры:

Нажимаем на «Run».

Получаем сервисы:

$ kubectl get svc
NAME             TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)        AGE
kubernetes       ClusterIP   10.96.0.1        <none>        443/TCP        178m
mytestapp-dev    ClusterIP   10.105.171.103   <none>        80/TCP         47m
mytestapp-prod   NodePort    10.109.30.179    <none>        80:30294/TCP   57m

Чтобы проверить, работает ли деплоймент, пробросим прокси куба:

$ kubectl proxy
Starting to serve on 127.0.0.1:8001

ЗАМЕЧАНИЕ: для того чтобы прокси работал в бэкграунде, выполняем:

$ kubectl proxy &

Т.к я деплоил mytestapp-prod приложение, а оно находится на http://127.0.0.1:30294/ то кликаем по нему и попадаем собственно на задеплоенный nginx!

Стоит выполнить ряд действий для dev стейджа. Клацаем «Pipelines» -> «Create». Название выбираем название «DeployToDev»:

После чего. Нажимаем на «Save Changes». И кликаем «Add Stage»:

Заполняем:

• Type -> Deploy.
• Stage Name -> Deploy.

В поле «Add server group», выбераем «mytestapp-prod-v000»:

Выбираем из списка и нажимаем на «Use this template». Он скопирует темплейт в новый. Немного поправим его:

Далее, в поле «Load Balancers»:

Заменили и идем в «Container»:

Во вкладке «Probes», включаем Readiness Probe и Liveness Probe (как в примерах выше). После всех настроек, клацаем на «Add» -> «Save Changes».

Вернусь в главное меню апликейшина и нажму на только созданный пайплайн:

Скачаем дашборды для куба:

$ kubectl apply -f https://raw.githubusercontent.com/kubernetes/dashboard/master/aio/deploy/recommended/kubernetes-dashboard.yaml

Смотрим токены:

$ kubectl -n kube-system describe secret $(kubectl -n kube-system get secret | grep admin-user | awk '{print $1}')

Открываем — http://localhost:8001/api/v1/namespaces/kube-system/services/https:kubernetes-dashboard:/proxy/

С помощью данных бордов можно смотреть инфу.

В завершении, содаем новый пайплайн с названием PromoteToProd:

Жмакаем на «Create». И заполняем поля:

Нажимаем на «Save Changes». После чего, открываем «Add Stage»:

Заполняем и клацаем на «Save Changes». Клацаем на «Add stage» для создания деплоя на ПРОД:

Клацаем на «Add server group» и выбераем «Copy configuration from», а имеено с «None» и кликаем на «Continue without any templates». Заполняем:

Кликаем на «Add» -> «Save Changes».

Нажимаем на билды. Перекидываем с dev -> prod:

Проверяем через ИП деплой! Все должно работать.

Вот и все, статья «Установка Spinnaker в Unix/Linux» завершена.

Concourse CI — это современная система непрерывной интеграции, которая автоматизирует конвейеры тестирования.

Он очень самоуверен в нескольких вещах:

• Идемпотентность,
• Неизменность,
• Имеет декларативный конфиг,
• Stateless workers (воркеры без сохранения состояния),
• Воспроизводимые сборки.

Пайплайн выглядит следующим образом:

Перейдем к установке.

Установка Concourse CI в Unix/Linux

Concourse можно установить несколькими способами. Приведу примеры установок.

Установка Concourse CI используя бинарный файл

Скачиваем архивы (для MacOS):

$ wget https://github.com/concourse/concourse/releases/download/v5.3.0/concourse-5.3.0-darwin-amd64.tgz && wget https://github.com/concourse/concourse/releases/download/v5.3.0/fly-5.3.0-darwin-amd64.tgz

Скачиваем архивы (для Linux):

$ wget https://github.com/concourse/concourse/releases/download/v5.3.0/concourse-5.3.0-linux-amd64.tgz && wget https://github.com/concourse/concourse/releases/download/v5.3.0/fly-5.3.0-linux-amd64.tgz

Замините архивы для своих целей (версию или тип ОС).

Распаковываем:

$ tar -xfvz concourse-*.tgz -C /usr/local
$ tar -xfvz fly-*.tgz -C /usr/local

ЗАМЕЧАНИЕ: Нужно добавить PATH для использования данных тулов (если этого не было сделано). Например, у меня такой:

export PATH="$PATH:/usr/local/bin:/usr/local/sbin:/opt/X11/bin:/usr/local/git/bin:/usr/local/go/bin:/sbin:/bin:/opt/local/bin:/opt/local/sbin"

Добавил я его в:

$ vim ~/.bash_profile 

Чтобы настройка применилась, выполняем:

$ source ~/.bash_profile 

или:

$ . ~/.bash_profile 

Вот и вся установка.

Установка Concourse CI используя исходный код

Скачаем архив:

$ wget -O concourse-latest.tar.gz https://github.com/concourse/concourse/archive/v5.3.0.tar.gz

Распаковываем:

$ tar xfvz concourse-latest.tar.gz

В папке concourse-5.3.0 лежит исходный код ( на golang). Можно перейти в папку и скомпилировать:

$ cd concourse-*

PS: Компилировать я не стал (не было необходимости). Использую докер для своих реализаций. Будет время, дополню материал….

Возможно, кто-то хочет помогать мне в этом — я буду не против.

Установка Concourse CI используя Docker

Ставим Docker, docker-compose, статьи вот тут:

Установка Docker на CentOS/RedHat/Fedora

Установка Docker на Debian/Ubuntu

Установка docker-compose в Unix/Linux

Работа с docker + docker-compose в Unix/Linux

Другие полезные статьи:

Запустить Docker контейнер от пользователя в Unix/Linux

Создание docker контейнера в Unix/Linux

Остановить/Удалить все Docker контейнеры/images

Запуск docker контейнеров в Unix/Linux

Запустить bash/SSH в контейнере с Docker

Использование статического IP адреса в docker-compose

Работа с сетью (Networking) в Docker

Работа с томами (Volumes) в Docker

Работа с логами (Logs) в Docker

Приступим….

Для консоурса, нужны 3 сервиса, можно получить помощь так:

$ docker run -t concourse/concourse --help
$ docker run -t concourse/concourse web --help
$ docker run -t concourse/concourse worker --help

Понять что и как работает и потом запустить. Честно говоря, я не использовал данный вариант, я использовал установку через docker-compose. Скачиваем файл:

$ wget https://concourse-ci.org/docker-compose.yml

Запускаем билд консоурса:

$ docker-compose up
Creating docs_concourse-db_1 ... done
Creating docs_concourse_1    ... done

PS: Можно скачать архив (вытянуть все через git):

$ git clone https://github.com/concourse/concourse-docker.git && cd concourse-docker

Можно сгенерировать ключи:

$ ./keys/generate
Unable to find image 'concourse/concourse:latest' locally
latest: Pulling from concourse/concourse
6abc03819f3e: Already exists
05731e63f211: Already exists
0bd67c50d6be: Already exists
f81c432f3eb1: Pull complete
28ed15a59bee: Pull complete
Digest: sha256:df37aa611cc0f75fdd400665a0c422211974cbfe09d3cca6311cc90b17a079e2
Status: Downloaded newer image for concourse/concourse:latest
wrote private key to /keys/session_signing_key
wrote private key to /keys/tsa_host_key
wrote ssh public key to /keys/tsa_host_key.pub
wrote private key to /keys/worker_key
wrote ssh public key to /keys/worker_key.pub

Ну и потом выполнить запуск сервиса:

$ docker-compose up -d
Creating network "concourse-docker_default" with the default driver
Pulling db (postgres:)...
latest: Pulling from library/postgres
fc7181108d40: Pull complete
81cfa12d39e9: Pull complete
793d305ca761: Pull complete
41e3ced3a2aa: Pull complete
a300bc9d5405: Pull complete
3c6a5c3830ed: Pull complete
fb8c79b24338: Pull complete
fcda1144379f: Pull complete
476a22a819cc: Pull complete
78b36b49bb24: Pull complete
6a096a28591f: Pull complete
c0cb89b5217b: Pull complete
778f1469a309: Pull complete
7c4413fcad87: Pull complete
Digest: sha256:1518027f4aaee49b836c5cf4ece1b4a16bdcd820af873402e19e1cc181c1aff2
Status: Downloaded newer image for postgres:latest
Creating concourse-docker_db_1 ... done
Creating concourse-docker_web_1 ... done
Creating concourse-docker_worker_1 ... done

Чтобы проверить старталули ли сервисы, проверяем:

$ docker ps

Поглядеть логи, можно так:

$ docker-compose logs -f

Если все стартануло и без каких либо ошибок, — переходим к проверке работоспсобности и настройке.

Установка Concourse CI используя BOSH

Пока, не было обходимости в этой настройке…

Установка Concourse CI используя Kubernetes

Установка k8s описана тут:

Установка Kubernetes в Unix/Linux

Установка Kubernetes кластера в Unix/Linux

Ставим утилиту через чарт:

$ helm install --name concourse-ci stable/concourse

Удалить можно так:

$ helm delete concourse-ci

На этом у меня закончилось тестирование concourse-ci. Перейдем к использованию.

Настройка Concourse CI в Unix/Linux

Я установил Concourse через docker-compose. После установки данной утилиты, сервис должен работать по 127.0.0.1:8080 УРЛ. Выглядит это так:

Как видно с экрана, можно выполнить вход в панель, для этого нажать нужно на «Login». Логин/пароль — test и test.

Fly — это утилита командной строки, которая позволяет управлять всем вашим кластером ConcourseCI из терминала. Ставится на ваш рабочий компьютер и упралвяет сервером. С ней вы можете совершать все необходимые операции и обслуживать кластер.

Скачиваем утилиту fly:

• Если вы сиспользуете MacOS:

$ wget -O /usr/local/bin/fly --user=test --password=test "http://localhost:8080/api/v1/cli?arch=amd64&platform=darwin"

• Если вы сиспользуете Linux:
  
  

$ wget -O /usr/local/bin/fly --user=test --password=test "http://localhost:8080/api/v1/cli?arch=amd64&platform=linux"

После скачивания файла, выставим права на исполнение данного бинарника:

$ chmod +x /usr/local/bin/fly

Получить помошь, можно:

$ fly --help

Выполним вход в сервис через утилиту fly:

$ fly -t ci login -c http://127.0.0.1:8080 -u test -p test
logging in to team 'main'


target saved

Смотрим какой таргет используем сейчас:

$ fly targets
name  url                    team  expiry
ci    http://127.0.0.1:8080  main  Sat, 15 Jun 2019 13:05:43 UTC

Проверить статус можно так:

$ fly -t ci status
logged in successfully

Смотрим информацию по таргету:

$ fly -t ci userinfo
username  team/role
test      main/owner

Чтобы выйти:

$ fly -t ci logout

Чтобы очистить свой токен для всех targets:

$ fly logout -a

Чтобы изменить имя, команду или URL-адрес target-а, выполните:

$ fly -t ci edit-target \
    --target-name new-name \
    --concourse-url http://127.0.0.1:8080 \
    --team-name my-team
Updated target: ci

И проверяем что вышло:

$ fly targets
name      url                    team     expiry
new-name  http://127.0.0.1:8080  my-team  Sat, 15 Jun 2019 13:05:43 UTC

Удалить таргет можно следующим образом:

$ fly -t new-name delete-target

Чтобы удалить все таргеты, выполните:

$ fly delete-target -a

Время от времени утилиты обновляетсяи выходят релизы, чтобы обновить локальную версию тулы можно использовать:

$ fly -t new-name sync
version 5.3.0 already matches; skipping

Работа с локальными юзерами (Добавление/Удаление) в concourse

Все операции с юзерами выполняються на web ноде, т.к я использую докер, для добавление юзеров, стоит открыть:

$ vim docker-compose.yml

И привести к виду:

CONCOURSE_ADD_LOCAL_USER: test:test,your_user:your_password
CONCOURSE_MAIN_TEAM_LOCAL_USER: test,your_user

Ну и потом, запустить:

$ docker-compose up -d

Проверим:

$ fly --target ci login --username=captain --password=captain --team-name main
logging in to team 'main'


target saved

Работа с team-ами в concourse

Пример создания тимы:

$ fly -t ci set-team --team-name new-team \
 >   --local-user captain
setting team: new-team

role owner:
  users:
  - local:captain

  groups:
    none

apply team configuration? [yN]: y
team created

Логинимся в тиму:

$ fly --target ci login -n new-team --concourse-url http://localhost:8080 -k -u captain  -p captain

Чтобы посмотреть team-ы:

$ fly -t ci teams
name
main
new-team

Или, с более подробной инфой:

$ fly -t ci teams -d
name/role       users                     groups
main/owner      local:test,local:captain  none
new-team/owner  local:captain             none

Чтобы посмотреть найтройки тимы, выполните:

$ fly -t ci get-team -n new-team
name/role       users          groups
new-team/owner  local:captain  none

Для переименования тимы, можно заюзать:

$ fly -t ci rename-team --old-name new-team --new-name cool-team
Team successfully renamed to cool-team

Смотрим что вышло:

$ fly -t ci teams
name
cool-team
main

Для удаления тимы, служит команда:

$ fly -t ci destroy-team --team-name cool-team
!!! this will remove all data for team `cool-team`

please type the team name to confirm: cool-team

`cool-team` deleted

Приступим к пайплайнам.

Конфигурация Concourse CI pipeline-ов в Unix/Linux

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

Логинимся:

$ fly -t ci login -c http://127.0.0.1:8080 -u captain -p captain
logging in to team 'main'


target saved

Чтобы просмотреть список настроенных конвейеров и их приостановленное состояние, выполните:

$ fly -t ci pipelines
name  paused  public

Т.к у меня чистый\только созданный проект, у меня нет никаких пайплайнов.

Чтобы переименовать конвейер, запустите:

$ fly -t ci rename-pipeline \
    --old-name my-pipeline \
    --new-name my-cool-pipeline

Чтобы приостановить конвейер, запустите:

$ fly -t ci pause-pipeline --pipeline pipeline_name_here

Данная команда, предотвратит планирование заданий и прекратит периодическую проверку новых версий ресурсов. Сборки, которые находятся уже в запуске, будут закончены.

Чтобы снять с паузы пайплайн, запустите:

$ fly -t ci unpause-pipeline --pipeline pipeline_name_here

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

$ fly -t ci expose-pipeline --pipeline pipeline_name_here

Если вы понимаете, что совершили ужасную ошибку что дали доступ к пайплайну другим тимам, можно скрыть:

$ fly -t ci hide-pipeline --pipeline pipeline_name_here

Fly можно использовать для получения и обновления конфигурации ваших конвейеров. Например, чтобы получить текущую конфигурацию вашего конвейера и вывести ее в STDOUT, выполните следующее:

$ fly -t ci get-pipeline --pipeline pipeline_name_here

PS: чтобы получить вывод в JSON вместо YAML, вы можете использовать аргумент -j или —json. Это может быть полезно при проверке вашей конфигурации с утилитой jq.

Чтобы остановить работу конвейера и удалить все данные, собранные конвейером, включая историю сборки и собранные версии, можно выполнив:

$ fly -t ci destroy-pipeline --pipeline pipeline_name_here

Чтобы настроить порядок трубопроводов, выполните:

$ fly -t ci order-pipelines \
    --pipeline pipeline-1 \
    --pipeline pipeline-2 \
    --pipeline pipeline-3

Обратите внимание, что эта команда только гарантирует то, что указанные конвейеры находятся в заданном порядке. Если есть другие пайплайны, которые вы не включили в данную команду, они могут появляться между, до или после заданного набора.

Для валидации, можно использовать:

$ fly validate-pipeline --config your_pipeline_name_here.yml
looks good

Так же, можно выполнить команду и проверить форматинг:

$ fly format-pipeline --config your_pipeline_name_here.yml

Перейдем к примеру(ам). У Concourse еет графического интерфейса для настройки пайплайнов и вместо этого, пайплайны настраиваются как декларативные YAML файлы. Выглядит это так:

jobs:
- name: hello-world
  plan:
  - task: say-hello
    config:
      platform: linux
      image_resource:
        type: docker-image
        source: {repository: alpine}
      run:
        path: echo
        args: ["Hello, world!"]

Сохраните данный вывод в файл (например: hello.yml) и потом, запустите:

$ fly -t ci set-pipeline -p hello -c hello.yml
jobs:
  job hello-world has been added:
+ name: hello-world
+ plan:
+ - task: say-hello
+   config:
+     platform: linux
+     image_resource:
+       type: docker-image
+       source:
+         repository: alpine
+     run:
+       path: echo
+       args:
+       - Hello, world!

apply configuration? [yN]: y
pipeline created!
you can view your pipeline here: http://127.0.0.1:8080/teams/main/pipelines/hello

the pipeline is currently paused. to unpause, either:
  - run the unpause-pipeline command:
    fly -t ci unpause-pipeline -p hello
  - click play next to the pipeline in the web ui

Написало что нужно анпаузить проект:

$ fly -t ci unpause-pipeline -p hello
unpaused 'hello'

Открываем веб-линку с консоурсом и смотрим что вышло. Написание пайплайнов будет позже. Я дополню данную статью или создам новую.

Вот и все, статья «Установка Concourse CI в Unix/Linux» завершена.

GitLab Runner — это агент, который собственно и занимается выполнением инструкций из специального файла .gitlab-ci.yml

Полезное чтиво:

Установка GitLab сервер в Unix/Linux

Установка GitLab-Runner-а в Unix/Linux

Сейчас я расскажу как можно настроить gitlab-runner на разные Unix/Linux ОС. Но для начала, запустим сервисы.

Установка GitLab-Runner-а в Mac OS X

Скачиваем бинарник:

$ sudo curl --output /usr/local/bin/gitlab-runner https://gitlab-runner-downloads.s3.amazonaws.com/latest/binaries/gitlab-runner-darwin-amd64

Конечно же, выставить права нужно:

$ sudo chmod +x /usr/local/bin/gitlab-runner

После того как выставили права, необходимо зарегестрировать гитлаб-ранер, например, это можно сделать следующим образом:

$ gitlab-runner register --url=http://gitlab.local/ --registration-token=xyLWaXwd15xy6VxU7HUV --non-interactive=true --locked=false --name=gitlab-runner-macosx --executor=docker --docker-image=docker:stable --docker-volumes=/var/run/docker.sock:/var/run/docker.sock

Где:

• gitlab-runner — Утилита.
• register — Опция для регистрации гитлаб-раннера.
• —url=http://gitlab.local — УРЛ где базируется гитлаб-сервер.
• —registration-token=xyLWaXwd15xy6VxU7HUV — Токен для регистрации раннера. Можно найти в админ-панели гитлаб-сервера («Admin Area»-> «Runners»).
• —non-interactive=true — Не выводить вывод на экран.
• —locked=false — Не лочить ранер.
• —name=gitlab-runner-macosx — Собственно имя с которым будет регистрироватся гитлаб-раннер.
• —executor=docker — Выбираем экзекутера (docker или shell). У меня docker.
• —docker-image=docker:stable — Выбираем докер имедж.
• —docker-volumes=/var/run/docker.sock:/var/run/docker.sock — Пробросил докер сокет.

Для помощи есть команда:

$ gitlab-runner register -h
Runtime platform                                    arch=amd64 os=linux pid=137 revision=8bb608ff version=11.7.0
NAME:
   gitlab-runner register - register a new runner

USAGE:
   gitlab-runner register [command options] [arguments...]

OPTIONS:
   -c value, --config value                              Config file (default: "/etc/gitlab-runner/config.toml") [$CONFIG_FILE]
   --tag-list value                                      Tag list [$RUNNER_TAG_LIST]
   -n, --non-interactive                                 Run registration unattended [$REGISTER_NON_INTERACTIVE]
   --leave-runner                                        Don't remove runner if registration fails [$REGISTER_LEAVE_RUNNER]
   -r value, --registration-token value                  Runner's registration token [$REGISTRATION_TOKEN]
   --run-untagged                                        Register to run untagged builds; defaults to 'true' when 'tag-list' is empty [$REGISTER_RUN_UNTAGGED]
   --locked                                              Lock Runner for current project, defaults to 'true' [$REGISTER_LOCKED]
   --maximum-timeout value                               What is the maximum timeout (in seconds) that will be set for job when using this Runner (default: "0") [$REGISTER_MAXIMUM_TIMEOUT]
   --paused                                              Set Runner to be paused, defaults to 'false' [$REGISTER_PAUSED]
   --name value, --description value                     Runner name (default: "7e2764bb1d36") [$RUNNER_NAME]
   --limit value                                         Maximum number of builds processed by this runner (default: "0") [$RUNNER_LIMIT]
   --output-limit value                                  Maximum build trace size in kilobytes (default: "0") [$RUNNER_OUTPUT_LIMIT]
   --request-concurrency value                           Maximum concurrency for job requests (default: "0") [$RUNNER_REQUEST_CONCURRENCY]
   -u value, --url value                                 Runner URL [$CI_SERVER_URL]
   -t value, --token value                               Runner token [$CI_SERVER_TOKEN]
   --tls-ca-file value                                   File containing the certificates to verify the peer when using HTTPS [$CI_SERVER_TLS_CA_FILE]
   --tls-cert-file value                                 File containing certificate for TLS client auth when using HTTPS [$CI_SERVER_TLS_CERT_FILE]
   --tls-key-file value                                  File containing private key for TLS client auth when using HTTPS [$CI_SERVER_TLS_KEY_FILE]
   --executor value                                      Select executor, eg. shell, docker, etc. [$RUNNER_EXECUTOR]
   --builds-dir value                                    Directory where builds are stored [$RUNNER_BUILDS_DIR]
   --cache-dir value                                     Directory where build cache is stored [$RUNNER_CACHE_DIR]
   --clone-url value                                     Overwrite the default URL used to clone or fetch the git ref [$CLONE_URL]
   --env value                                           Custom environment variables injected to build environment [$RUNNER_ENV]
   --pre-clone-script value                              Runner-specific command script executed before code is pulled [$RUNNER_PRE_CLONE_SCRIPT]
   --pre-build-script value                              Runner-specific command script executed after code is pulled, just before build executes [$RUNNER_PRE_BUILD_SCRIPT]
   --post-build-script value                             Runner-specific command script executed after code is pulled and just after build executes [$RUNNER_POST_BUILD_SCRIPT]
   --shell value                                         Select bash, cmd or powershell [$RUNNER_SHELL]
   --ssh-user value                                      User name [$SSH_USER]
   --ssh-password value                                  User password [$SSH_PASSWORD]
   --ssh-host value                                      Remote host [$SSH_HOST]
   --ssh-port value                                      Remote host port [$SSH_PORT]
   --ssh-identity-file value                             Identity file to be used [$SSH_IDENTITY_FILE]
   --docker-host value                                   Docker daemon address [$DOCKER_HOST]
   --docker-cert-path value                              Certificate path [$DOCKER_CERT_PATH]
   --docker-tlsverify                                    Use TLS and verify the remote [$DOCKER_TLS_VERIFY]
   --docker-hostname value                               Custom container hostname [$DOCKER_HOSTNAME]
   --docker-image value                                  Docker image to be used [$DOCKER_IMAGE]
   --docker-runtime value                                Docker runtime to be used [$DOCKER_RUNTIME]
   --docker-memory value                                 Memory limit (format: <number>[<unit>]). Unit can be one of b, k, m, or g. Minimum is 4M. [$DOCKER_MEMORY]
   --docker-memory-swap value                            Total memory limit (memory + swap, format: <number>[<unit>]). Unit can be one of b, k, m, or g. [$DOCKER_MEMORY_SWAP]
   --docker-memory-reservation value                     Memory soft limit (format: <number>[<unit>]). Unit can be one of b, k, m, or g. [$DOCKER_MEMORY_RESERVATION]
   --docker-cpuset-cpus value                            String value containing the cgroups CpusetCpus to use [$DOCKER_CPUSET_CPUS]
   --docker-cpus value                                   Number of CPUs [$DOCKER_CPUS]
   --docker-dns value                                    A list of DNS servers for the container to use [$DOCKER_DNS]
   --docker-dns-search value                             A list of DNS search domains [$DOCKER_DNS_SEARCH]
   --docker-privileged                                   Give extended privileges to container [$DOCKER_PRIVILEGED]
   --docker-disable-entrypoint-overwrite                 Disable the possibility for a container to overwrite the default image entrypoint [$DOCKER_DISABLE_ENTRYPOINT_OVERWRITE]
   --docker-userns value                                 User namespace to use [$DOCKER_USERNS_MODE]
   --docker-cap-add value                                Add Linux capabilities [$DOCKER_CAP_ADD]
   --docker-cap-drop value                               Drop Linux capabilities [$DOCKER_CAP_DROP]
   --docker-oom-kill-disable                             Do not kill processes in a container if an out-of-memory (OOM) error occurs [$DOCKER_OOM_KILL_DISABLE]
   --docker-security-opt value                           Security Options [$DOCKER_SECURITY_OPT]
   --docker-devices value                                Add a host device to the container [$DOCKER_DEVICES]
   --docker-disable-cache                                Disable all container caching [$DOCKER_DISABLE_CACHE]
   --docker-volumes value                                Bind mount a volumes [$DOCKER_VOLUMES]
   --docker-volume-driver value                          Volume driver to be used [$DOCKER_VOLUME_DRIVER]
   --docker-cache-dir value                              Directory where to store caches [$DOCKER_CACHE_DIR]
   --docker-extra-hosts value                            Add a custom host-to-IP mapping [$DOCKER_EXTRA_HOSTS]
   --docker-volumes-from value                           A list of volumes to inherit from another container [$DOCKER_VOLUMES_FROM]
   --docker-network-mode value                           Add container to a custom network [$DOCKER_NETWORK_MODE]
   --docker-links value                                  Add link to another container [$DOCKER_LINKS]
   --docker-services value                               Add service that is started with container [$DOCKER_SERVICES]
   --docker-wait-for-services-timeout value              How long to wait for service startup (default: "0") [$DOCKER_WAIT_FOR_SERVICES_TIMEOUT]
   --docker-allowed-images value                         Whitelist allowed images [$DOCKER_ALLOWED_IMAGES]
   --docker-allowed-services value                       Whitelist allowed services [$DOCKER_ALLOWED_SERVICES]
   --docker-pull-policy value                            Image pull policy: never, if-not-present, always [$DOCKER_PULL_POLICY]
   --docker-shm-size value                               Shared memory size for docker images (in bytes) (default: "0") [$DOCKER_SHM_SIZE]
   --docker-tmpfs value                                  A toml table/json object with the format key=values. When set this will mount the specified path in the key as a tmpfs volume in the main container, using the options specified as key. For the supported options, see the documentation for the unix 'mount' command (default: "{}") [$DOCKER_TMPFS]
   --docker-services-tmpfs value                         A toml table/json object with the format key=values. When set this will mount the specified path in the key as a tmpfs volume in all the service containers, using the options specified as key. For the supported options, see the documentation for the unix 'mount' command (default: "{}") [$DOCKER_SERVICES_TMPFS]
   --docker-sysctls value                                Sysctl options, a toml table/json object of key=value. Value is expected to be a string. (default: "{}") [$DOCKER_SYSCTLS]
   --docker-helper-image value                           [ADVANCED] Override the default helper image used to clone repos and upload artifacts [$DOCKER_HELPER_IMAGE]
   --parallels-base-name value                           VM name to be used [$PARALLELS_BASE_NAME]
   --parallels-template-name value                       VM template to be created [$PARALLELS_TEMPLATE_NAME]
   --parallels-disable-snapshots                         Disable snapshoting to speedup VM creation [$PARALLELS_DISABLE_SNAPSHOTS]
   --virtualbox-base-name value                          VM name to be used [$VIRTUALBOX_BASE_NAME]
   --virtualbox-base-snapshot value                      Name or UUID of a specific VM snapshot to clone [$VIRTUALBOX_BASE_SNAPSHOT]
   --virtualbox-disable-snapshots                        Disable snapshoting to speedup VM creation [$VIRTUALBOX_DISABLE_SNAPSHOTS]
   --cache-type value                                    Select caching method [$CACHE_TYPE]
   --cache-path value                                    Name of the path to prepend to the cache URL [$CACHE_PATH]
   --cache-shared                                        Enable cache sharing between runners. [$CACHE_SHARED]
   --cache-s3-server-address value                       A host:port to the used S3-compatible server [$CACHE_S3_SERVER_ADDRESS]
   --cache-s3-access-key value                           S3 Access Key [$CACHE_S3_ACCESS_KEY]
   --cache-s3-secret-key value                           S3 Secret Key [$CACHE_S3_SECRET_KEY]
   --cache-s3-bucket-name value                          Name of the bucket where cache will be stored [$CACHE_S3_BUCKET_NAME]
   --cache-s3-bucket-location value                      Name of S3 region [$CACHE_S3_BUCKET_LOCATION]
   --cache-s3-insecure                                   Use insecure mode (without https) [$CACHE_S3_INSECURE]
   --cache-gcs-access-id value                           ID of GCP Service Account used to access the storage [$CACHE_GCS_ACCESS_ID]
   --cache-gcs-private-key value                         Private key used to sign GCS requests [$CACHE_GCS_PRIVATE_KEY]
   --cache-gcs-credentials-file value                    File with GCP credentials, containing AccessID and PrivateKey [$GOOGLE_APPLICATION_CREDENTIALS]
   --cache-gcs-bucket-name value                         Name of the bucket where cache will be stored [$CACHE_GCS_BUCKET_NAME]
   --cache-s3-cache-path value                           Name of the path to prepend to the cache URL. DEPRECATED [$S3_CACHE_PATH]
   --cache-cache-shared                                  Enable cache sharing between runners. DEPRECATED
   --machine-idle-nodes value                            Maximum idle machines (default: "0") [$MACHINE_IDLE_COUNT]
   --machine-idle-time value                             Minimum time after node can be destroyed (default: "0") [$MACHINE_IDLE_TIME]
   --machine-max-builds value                            Maximum number of builds processed by machine (default: "0") [$MACHINE_MAX_BUILDS]
   --machine-machine-driver value                        The driver to use when creating machine [$MACHINE_DRIVER]
   --machine-machine-name value                          The template for machine name (needs to include %s) [$MACHINE_NAME]
   --machine-machine-options value                       Additional machine creation options [$MACHINE_OPTIONS]
   --machine-off-peak-periods value                      Time periods when the scheduler is in the OffPeak mode [$MACHINE_OFF_PEAK_PERIODS]
   --machine-off-peak-timezone value                     Timezone for the OffPeak periods (defaults to Local) [$MACHINE_OFF_PEAK_TIMEZONE]
   --machine-off-peak-idle-count value                   Maximum idle machines when the scheduler is in the OffPeak mode (default: "0") [$MACHINE_OFF_PEAK_IDLE_COUNT]
   --machine-off-peak-idle-time value                    Minimum time after machine can be destroyed when the scheduler is in the OffPeak mode (default: "0") [$MACHINE_OFF_PEAK_IDLE_TIME]
   --kubernetes-host value                               Optional Kubernetes master host URL (auto-discovery attempted if not specified) [$KUBERNETES_HOST]
   --kubernetes-cert-file value                          Optional Kubernetes master auth certificate [$KUBERNETES_CERT_FILE]
   --kubernetes-key-file value                           Optional Kubernetes master auth private key [$KUBERNETES_KEY_FILE]
   --kubernetes-ca-file value                            Optional Kubernetes master auth ca certificate [$KUBERNETES_CA_FILE]
   --kubernetes-bearer_token_overwrite_allowed           Bool to authorize builds to specify their own bearer token for creation. [$KUBERNETES_BEARER_TOKEN_OVERWRITE_ALLOWED]
   --kubernetes-bearer_token value                       Optional Kubernetes service account token used to start build pods. [$KUBERNETES_BEARER_TOKEN]
   --kubernetes-image value                              Default docker image to use for builds when none is specified [$KUBERNETES_IMAGE]
   --kubernetes-namespace value                          Namespace to run Kubernetes jobs in [$KUBERNETES_NAMESPACE]
   --kubernetes-namespace_overwrite_allowed value        Regex to validate 'KUBERNETES_NAMESPACE_OVERWRITE' value [$KUBERNETES_NAMESPACE_OVERWRITE_ALLOWED]
   --kubernetes-privileged                               Run all containers with the privileged flag enabled [$KUBERNETES_PRIVILEGED]
   --kubernetes-cpu-limit value                          The CPU allocation given to build containers [$KUBERNETES_CPU_LIMIT]
   --kubernetes-memory-limit value                       The amount of memory allocated to build containers [$KUBERNETES_MEMORY_LIMIT]
   --kubernetes-service-cpu-limit value                  The CPU allocation given to build service containers [$KUBERNETES_SERVICE_CPU_LIMIT]
   --kubernetes-service-memory-limit value               The amount of memory allocated to build service containers [$KUBERNETES_SERVICE_MEMORY_LIMIT]
   --kubernetes-helper-cpu-limit value                   The CPU allocation given to build helper containers [$KUBERNETES_HELPER_CPU_LIMIT]
   --kubernetes-helper-memory-limit value                The amount of memory allocated to build helper containers [$KUBERNETES_HELPER_MEMORY_LIMIT]
   --kubernetes-cpu-request value                        The CPU allocation requested for build containers [$KUBERNETES_CPU_REQUEST]
   --kubernetes-memory-request value                     The amount of memory requested from build containers [$KUBERNETES_MEMORY_REQUEST]
   --kubernetes-service-cpu-request value                The CPU allocation requested for build service containers [$KUBERNETES_SERVICE_CPU_REQUEST]
   --kubernetes-service-memory-request value             The amount of memory requested for build service containers [$KUBERNETES_SERVICE_MEMORY_REQUEST]
   --kubernetes-helper-cpu-request value                 The CPU allocation requested for build helper containers [$KUBERNETES_HELPER_CPU_REQUEST]
   --kubernetes-helper-memory-request value              The amount of memory requested for build helper containers [$KUBERNETES_HELPER_MEMORY_REQUEST]
   --kubernetes-pull-policy value                        Policy for if/when to pull a container image (never, if-not-present, always). The cluster default will be used if not set [$KUBERNETES_PULL_POLICY]
   --kubernetes-node-selector value                      A toml table/json object of key=value. Value is expected to be a string. When set this will create pods on k8s nodes that match all the key=value pairs. (default: "{}")
   --kubernetes-image-pull-secrets value                 A list of image pull secrets that are used for pulling docker image [$KUBERNETES_IMAGE_PULL_SECRETS]
   --kubernetes-helper-image value                       [ADVANCED] Override the default helper image used to clone repos and upload artifacts [$KUBERNETES_HELPER_IMAGE]
   --kubernetes-terminationGracePeriodSeconds value      Duration after the processes running in the pod are sent a termination signal and the time when the processes are forcibly halted with a kill signal. (default: "0") [$KUBERNETES_TERMINATIONGRACEPERIODSECONDS]
   --kubernetes-poll-interval value                      How frequently, in seconds, the runner will poll the Kubernetes pod it has just created to check its status (default: "0") [$KUBERNETES_POLL_INTERVAL]
   --kubernetes-poll-timeout value                       The total amount of time, in seconds, that needs to pass before the runner will timeout attempting to connect to the pod it has just created (useful for queueing more builds that the cluster can handle at a time) (default: "0") [$KUBERNETES_POLL_TIMEOUT]
   --kubernetes-pod-labels value                         A toml table/json object of key-value. Value is expected to be a string. When set, this will create pods with the given pod labels. Environment variables will be substituted for values here. (default: "{}")
   --kubernetes-service-account value                    Executor pods will use this Service Account to talk to kubernetes API [$KUBERNETES_SERVICE_ACCOUNT]
   --kubernetes-service_account_overwrite_allowed value  Regex to validate 'KUBERNETES_SERVICE_ACCOUNT' value [$KUBERNETES_SERVICE_ACCOUNT_OVERWRITE_ALLOWED]
   --kubernetes-pod-annotations value                    A toml table/json object of key-value. Value is expected to be a string. When set, this will create pods with the given annotations. Can be overwritten in build with KUBERNETES_POD_ANNOTATION_* varialbes (default: "{}")
   --kubernetes-pod_annotations_overwrite_allowed value  Regex to validate 'KUBERNETES_POD_ANNOTATIONS_*' values [$KUBERNETES_POD_ANNOTATIONS_OVERWRITE_ALLOWED]

Установим Runner как сервис и запустим его:

$ cd ~
$ gitlab-runner install
$ gitlab-runner start

Для обновления сервиса, нужно выполнить все теже действия что я описывал ранее, но перед этим, стоит остановить службу.

Вот и все использование.

Установка GitLab-Runner-а в GNU/Linux

Скачиваем бинарник в зависимости от разрядности и архитектуры ОС.

Если у вас, Linux x86-64:

$ sudo wget -O /usr/local/bin/gitlab-runner https://gitlab-runner-downloads.s3.amazonaws.com/latest/binaries/gitlab-runner-linux-amd64

Если у вас, Linux x86:

$ sudo wget -O /usr/local/bin/gitlab-runner https://gitlab-runner-downloads.s3.amazonaws.com/latest/binaries/gitlab-runner-linux-386

Если у вас, Linux arm:

$ sudo wget -O /usr/local/bin/gitlab-runner https://gitlab-runner-downloads.s3.amazonaws.com/latest/binaries/gitlab-runner-linux-arm

Конечно же, выставить права нужно:

$ sudo chmod +x /usr/local/bin/gitlab-runner

При желании, если вы хотите использовать Docker, установите Docker с:

$ curl -sSL https://get.docker.com/ | sh

Создайте пользователя GitLab CI:

$ sudo useradd --comment 'GitLab Runner' --create-home gitlab-runner --shell /bin/bash

После того как выставили права, необходимо установить Runner как сервис и запустить его:

$ sudo gitlab-runner install --user=gitlab-runner --working-directory=/home/gitlab-runner
$ sudo gitlab-runner start

Потом, зарегестрировать гитлаб-ранер, например, это можно сделать следующим образом:

$ gitlab-runner register --url=http://gitlab.local/ --registration-token=xyLWaXwd15xy6VxU7HUV --non-interactive=true --locked=false --name=gitlab-runner --executor=docker --docker-image=docker:stable --docker-volumes=/var/run/docker.sock:/var/run/docker.sock

Где:

• gitlab-runner — Утилита.
• register — Опция для регистрации гитлаб-раннера.
• —url=http://gitlab.local — УРЛ где базируется гитлаб-сервер.
• —registration-token=xyLWaXwd15xy6VxU7HUV — Токен для регистрации раннера. Можно найти в админ-панели гитлаб-сервера («Admin Area»-> «Runners»).
• —non-interactive=true — Не выводить вывод на экран.
• —locked=false — Не лочить ранер.
• —name=gitlab-runner-linux — Собственно имя с которым будет регистрироватся гитлаб-раннер.
• —executor=docker — Выбираем экзекутера (docker или shell). У меня docker.
• —docker-image=docker:stable — Выбираем докер имедж.
• —docker-volumes=/var/run/docker.sock:/var/run/docker.sock — Пробросил докер сокет.

Для обновления сервиса, нужно выполнить все теже действия что я описывал ранее, но перед этим, стоит остановить службу.

PS: Конечно если кто-то привык устанавливать программы через пакеты, то можно установить гитлаб-раннер через паркет. Приведу пару примеров:

Для Debian или Ubuntu:

$ wget https://s3.amazonaws.com/gitlab-runner-downloads/master/deb/gitlab-runner_i386.deb
$ wget https://s3.amazonaws.com/gitlab-runner-downloads/master/deb/gitlab-runner_amd64.deb
$ wget https://s3.amazonaws.com/gitlab-runner-downloads/master/deb/gitlab-runner_armel.deb
$ wget https://s3.amazonaws.com/gitlab-runner-downloads/master/deb/gitlab-runner_armhf.deb

А чтобы установить, можно выполнить:

$ dpkg -i gitlab-runner_386.deb

Для RedHat или CentOS:

$ wget https://s3.amazonaws.com/gitlab-runner-downloads/master/rpm/gitlab-runner_i686.rpm
$ wget https://s3.amazonaws.com/gitlab-runner-downloads/master/rpm/gitlab-runner_amd64.rpm
$ wget https://s3.amazonaws.com/gitlab-runner-downloads/master/rpm/gitlab-runner_arm.rpm
$ wget https://s3.amazonaws.com/gitlab-runner-downloads/master/rpm/gitlab-runner_armhf.rpm

Установить:

$ rpm -i gitlab-runner_386.rpm

PS: Если у вас проблемы с ссылками, попробуйте использовать http/https (В зависимости от того что используете на данный момент).

Вот и все использование.

Установка GitLab-Runner-а в FreeBSD

Не было необходимости!

Установка GitLab-Runner-а через docker контейнер в Unix/Linux

Можно запустить контейнер, например следующим образом:

$ docker run -d --name gitlab-runner --restart always gitlab/gitlab-runner:latest

Или:

$ docker run -d --name gitlab-runner --restart always \
   -v /srv/gitlab-runner/config:/etc/gitlab-runner \
   -v /var/run/docker.sock:/var/run/docker.sock \
   gitlab/gitlab-runner:latest

Но после создания контейнера, стоит на него зайти:

$ docker exec -ti -u root gitlab-runner bash

И запустить регистрацию, я ее описывал ранее несколько раз.

Установка GitLab-Runner-а через Kubernetes

Не было обходимости пока еще.

Вот и все, статья «Установка GitLab-Runner-а в Unix/Linux» завершена.

Набрался немного опыта по установке и настройке Jenkins-а. Разобрался как писать свои собственные pipelin-ы и пришло время сделать билд и собрать что-то на Java. Для своего примера, я возьму код с Github-а и залью в гитлаб-сервер (локальный).

Полезное чтиво:

Установка Jenkins в Unix/Linux

Работа с Jenkins-CLI в Unix/Linux

Установка Docker в Debian’s

Установка Docker в RedHat’s

Установка Docker-compose в Unix/Linux

Установка Jenkins и Jenkins-slave в Unix/Linux

Установка Jenkins в Unix/Linux

Буду использовать докер для установки дженкинса. ОС которую я использую — Mac OS X. Мой docker-compose.yml файл выглядит следующим образом:

---
version: '3.5'
services:
    gitlab:
        image: gitlab/gitlab-ce:latest
        container_name: gitlab
        hostname: gitlab.local
        labels:
            local.gitlab.description: "Gitlab server"
        ports:
            - "443:443"
            - "80:80"
            - "2222:22"
        dns:
            - 10.17.0.3
            - 1.1.1.1
            - 74.82.42.42
        volumes:
            - "/usr/local/gitlab/config:/etc/gitlab:rw"
            - "/usr/local/gitlab/logs:/var/log/gitlab:rw"
            - "/usr/local/gitlab/data:/var/opt/gitlab:rw"
        extra_hosts:
            jenkins_local_docker: 172.6.6.20
            socat_container: 172.6.6.2
        restart: always
        environment:
            - GITLAB_OMNIBUS_CONFIG="external_url 'http://gitlab.local:80'; gitlab_rails['gitlab_shell_ssh_port']=2222; gitlab_rails['lfs_enabled'] = true;"
        networks:
            network0:
                ipv4_address: 172.6.6.10
        healthcheck:
            test: ["CMD", "curl", "-f", "http://gitlab.local"]
            interval: 5m
            timeout: 30s
            retries: 3
            start_period: 5m
    jenkins:
        image: jenkins/jenkins:latest
        container_name: jenkins
        hostname: jenkins.local
        ports:
            - "8080:8080"
            - "50000:50000"
        dns:
            - 10.17.0.3
            - 1.1.1.1
            - 74.82.42.42
        volumes:
            - "/usr/local/jenkins/data:/var/jenkins_home:rw"
            - "/usr/local/jenkins/backups:/backups:rw"
            - "/var/run/docker.sock:/var/run/docker.sock:rw"
            - "/usr/local/bin/docker:/bin/docker"
        extra_hosts:
            gitlab_local_docker: 172.6.6.10
            socat_container: 172.6.6.2
        restart: always
        privileged: true
        environment:
            - DOCKER_HOST=tcp://socat:2375
            - JAVA_OPTS="-Xmx2048M"
              #- JAVA_OPTS="-Xms512M -Xmn512m -Xmx1024m -Duser.timezone=Europe/Kiev -Dfile.encoding=UTF-8"
              #- JENKINS_OPTS=""
        links:
            - socat
        depends_on:
            - gitlab
        networks:
            network0:
                ipv4_address: 172.6.6.20
        pid: host
    socat:
        image: bpack/socat
        container_name: socat
        hostname: socat_container
        restart: "always"
        privileged: true
        ports:
            - "2375:2375"
        dns:
            - 10.17.0.3
            - 1.1.1.1
            - 74.82.42.42
        command: "TCP4-LISTEN:2375,fork,reuseaddr unix-connect:/var/run/docker.sock"
        volumes:
            - "/var/run/docker.sock:/var/run/docker.sock"
        networks:
            network0:
                ipv4_address: 172.6.6.2
#volumes:
    #docker_socket:
        #driver_opts:
        #   type: none
        #   device:  "/var/run/docker.sock"
        #   o: bind
networks:
  network0:
      ipam:
          driver: default
          config:
              - subnet: 172.6.6.0/24

Запустить стек можно следующим образом:

$ docker-compose -f /Users/captain/Projects/docker/jenkins_gitlab/docker-compose.yml up -d
Creating network "jenkins_gitlab_network0" with the default driver
Creating gitlab ... done
Creating socat  ... done
Creating jenkins ... done

Стек запущен и через несколько минут будет готов к использованию.

Работоспособность стека можно поглядеть:

$ docker ps
CONTAINER ID        IMAGE                     COMMAND                  CREATED             STATUS                             PORTS                                                            NAMES
0cde5390a8d1        jenkins/jenkins:latest    "/sbin/tini -- /usr/…"   51 seconds ago      Up 50 seconds                      0.0.0.0:8080->8080/tcp, 0.0.0.0:50000->50000/tcp                 jenkins
a89eaa4bd873        bpack/socat               "socat TCP4-LISTEN:2…"   52 seconds ago      Up 50 seconds                      0.0.0.0:2375->2375/tcp                                           socat
447dcb1faa0a        gitlab/gitlab-ce:latest   "/assets/wrapper"        52 seconds ago      Up 50 seconds (health: starting)   0.0.0.0:80->80/tcp, 0.0.0.0:443->443/tcp, 0.0.0.0:2222->22/tcp   gitlab

Как видно с вывода, gitlab все еще стартует. Ему потребуется 1-3 минуты (а поменяет свое состояние через 5 минут, т.к я создал свой хелз_чек) на то, чтобы запустится (healthy) чтобы запустится и работать.

Настройка Gitlab-сервера в Unix/Linux

Под настройкой гитлаб-сервера, я подразумеваю некоторые моменты, — например создания вебхука для дженкинса + добавления открытого ключа для пользователя git. Открываем УРЛ и переходим в админ-панель (http://gitlab.local/admin):

Нажимаем на «New user» (Это сразу под «Users») чтобы создать пользователя git. В этом нет ничего сложного. После того как создали, клацаем на «USERS:» (как на картинке, у меня всего 3 пользователя). Находим «git» пользователя которого создали и нажемаем по нему (Можно не логинится в данного юзера, а просто нажать на «impersonate» чтобы «стать им»). Затем, открываем профиль самого пользователя и переходим в поле «SSH Keys». Собственно в поле вставляем публичный\открытый ключ для подключения к гитлаб-серверу.

PS: я генерировал в 2048 битный ключ (если использовать 4096-битный, будет ошибка):

$ ssh-keygen -t rsa -C "The key for gitlab server" -f gitlab

Т.е вот так не сработает:

$ ssh-keygen -t rsa -b 4096 -C "The key for gitlab server" -f ~/.ssh/gitlab

PS: Конечно странно что нельзя использовать 4096-битный ключ. Возможно кто-то знает причину и поделится знаниями в коментариях.

Я создавал еще «Personal Access Tokens» не помню уже зачем, и нужно ли это вообще. Но оставил чтобы не забыть в случае надобности… Все это были настройки для git-юзера в его юзер-спейсе. Можно закрыть и перейти в админ-спейс, а именно в меню «System Hooks».

В поле URL, я вставил:

http://jenkins_local_docker:8080/generic-webhook-trigger/invoke?token=jenkins_token_to_gitlab

Где:

• http://jenkins_local_docker:8080 — Ссылка на дженкинс-сервер.
• generic-webhook-trigger/invoke — Плагин который устанавливали недавно (в дженкинсе).
• token=jenkins_token_to_gitlab — собственно сам токен, по которому будет происходить веб-хук. Выбрал простое название для токена (конечно не очень безопасное, но сойдет для локальной лабы).

В поле «Secret Token» собственно прописал токен, например у меня это:

jenkins_token_to_gitlab

В поле «Trigger» стоит отметить на что нужно реагировать. Я отметил все (не знаю зачем, но пусть будет), но можно было только «Repository update events», «Push events» и «Enable SSL verification», так же, если используете теги, то включаем «Tag push events», для мерджей стоит включить «Merge request events». Если нажать на «TEST», то можно проверить работоспособность вашего созданного веб-хука. У меня все огонь и я могу использовать его.

И да, нужно для юзера от которого будут идти коммиты в гитлаб-сервер, добавить открытый ключ. Собственно кто работает с гит-ом не один раз, помнит об этом…

В качестве примера сборки, я зашел на гитхаб и нашел «simple-java-maven-app» проект для моей сборки. Код содержит обычный «Hello world» и тесты для него + Pipelinefile + сборочный файл для maven-а (pom.xml). Код скачал на свою машину и выполнил пуш в свой гитлаб-сервер.

И так, теперь все готово к сборке!

Автосборка Java проектов через Jenkins в Unix/Linux

Если делали по моему docker-compose файлу, то я в /etc/hosts добавил (привел к виду):

#
#
#
127.0.0.1	localhost gitlab.local jenkins.local
255.255.255.255	broadcasthost
::1             localhost
#
#
#

Можно конечно и не делать и юзать localhost или 127.0.0.1 для входа на ресурсы, но так нагляднее и удобнее (как по мне).

Тогда гитлаб будет доступен по — http://gitlab.local:80/ , а дженкинс по — http://jenkins.local:8080. Это так, короткое отступление, если кто-то не знает как сделать или запустить. Сейчас тосит установить пару плагинов которые нам понадобяться. Чтобы это сделать, открываем «Manage Jenkins» -> «Manage Plugins» и переходим во «Available» вкладку. Потом можно использовать «Filter:» для поиска нужного плагина. Стоит установить — Gitlab Authentication plugin, GitLab Plugin, Generic Webhook Trigger Plugin. Почитать про них можно в интернете, моя статья заключается не в этом, по этому идем дельше.

Переходим на главную страницу и нажимаем на «New Item» чтобы создать проекты под себя. Я создал структуру которая имеет вид:

Projects->Java

Т.е в проектах будут лежать разные проекты для сборок (Java, Python, Go, PHP и может что-то еще). В папке с Java, создадим «Pipeline», названия могут быть любые, например — «simple-java-maven-app». Стоит перейти во вкладку «Pipeline» и заполнить все необходимые поля, у меня это выглядит вот так:

Я выбрал «Pipeline script from SCM», затем в поле SCM выбрал «Git». В поля репозиторий — я добавил урл на мой локальный гитлаб репозиторий с кодом, выглядит он вот так — git@gitlab_local_docker:java/simple-java-maven-app.git. В поле «Credentials» я добавил закрытый ключь от Gitlab-а (На гитлабе собственно положил открытый, для пользователя git). Конечно можно заполнять и другие вкладки руками, но я все необходимое вшил в свой пайплайн (Тем самым автоматизировал процесс) и данное действие необходимо только для 1-го запуска.

Гитлаб репозиторий с файлами выглядит следующим образом:

┌(captain@Macbook)─(✓)─(10:46 PM Sat Feb 09)
└─(~/Projects/gitlab/repos/simple-java-maven-app)─(6 files, 16b)─> tree
.
├── CHANGELOG
├── CONTRIBUTING.md
├── README.md
├── jenkins
│   ├── Jenkinsfile
│   ├── Jenkinsfile2
│   └── scripts
│       └── deliver.sh
├── pom.xml
└── src
    ├── main
    │   └── java
    │       └── com
    │           └── mycompany
    │               └── app
    │                   └── App.java
    └── test
        └── java
            └── com
                └── mycompany
                    └── app
                        └── AppTest.java

13 directories, 9 files

В «jenkins» папке лежат два Jenkinsfil-а (Jenkinsfile, Jenkinsfile2). Первый pipeline — это не измененный файл, т.е склонировал с проекта (все что шло в комплекте). А Jenkinsfile2 — это мой груви-код, который выглядит следующим образом:

#!/usr/bin/env groovy

properties([
    parameters([
        choice(name: 'GITLAB_PROTOCOL', choices: ['SSH', 'HTTP', 'HTTPS'],
            description: 'Set protocol for Gitlab usage (SSH, HTTP, HTTPS).'),
        string(name: 'GITLAB_SERVER', defaultValue: 'gitlab_local_docker'.toLowerCase(),
            description: 'Set GITLAB server or URL. I use hostname of my gilab docker container which linked to jenkins'),
        string(name: 'GITLAB_PROJECT', defaultValue: 'java'.toLowerCase(),
            description: 'Set GITLAB project.'),
        string(name: 'BRANCH_NAME', defaultValue: 'master',
               description: 'Service branch. Modify the build job config and change the Pipeline SCM branch to build using branch scripts.'),
        string(name: 'REPO_NAME', defaultValue: 'simple-java-maven-app'.toLowerCase(),
            description: 'Repo name')
    ]),
    //gitLabConnection('gitlab-private-key'),
    pipelineTriggers([
        [
            $class: 'GitLabPushTrigger',
            branchFilterType: 'All',
            triggerOnPush: true,
            triggerOnMergeRequest: false,
            triggerOpenMergeRequestOnPush: "never",
            triggerOnNoteRequest: true,
            noteRegex: "Jenkins please retry a build",
            skipWorkInProgressMergeRequest: true,
            secretToken: "jenkins_token_to_gitlab",
            ciSkip: false,
            setBuildDescription: true,
            addNoteOnMergeRequest: true,
            addCiMessage: true,
            addVoteOnMergeRequest: true,
            acceptMergeRequestOnSuccess: false,
            branchFilterType: "NameBasedFilter",
            includeBranchesSpec: "release/qat",
            excludeBranchesSpec: "",
        ],
        [
         $class: 'GenericTrigger',
         genericVariables: [
                  [key: 'ref', value: '$.ref'],
                  [key: 'before', value: '$.before',
                    expressionType: 'JSONPath', //Optional, defaults to JSONPath
                    regexpFilter: '', //Optional, defaults to empty string
                    defaultValue: '' //Optional, defaults to empty string
                  ]
        ],
        genericRequestVariables: [
                  [key: 'requestWithNumber', regexpFilter: '[^0-9]'],
                  [key: 'requestWithString', regexpFilter: '']
        ],
        genericHeaderVariables: [
                  [key: 'headerWithNumber', regexpFilter: '[^0-9]'],
                  [key: 'headerWithString', regexpFilter: '']
        ],
        causeString: 'Triggered on $ref',
        token: 'jenkins_token_to_gitlab',
        printContributedVariables: true,
        printPostContent: true,
        silentResponse: false,
        regexpFilterText: '$ref',
        regexpFilterExpression: 'refs/heads/' + env.BRANCH_NAME
        ]
    ])
])


pipeline {
    //tools {
    //    maven 'apache-maven-3.0.1'
    //    jdk "default"
    //}
    options {
        buildDiscarder(logRotator(artifactDaysToKeepStr: '', artifactNumToKeepStr: '5', daysToKeepStr: '', numToKeepStr: '5'))
        timeout(time: 60, unit: 'MINUTES')
        ansiColor('xterm')
        retry(1)
        timestamps()
        skipDefaultCheckout(true)
        parallelsAlwaysFailFast()
        disableConcurrentBuilds()
    }
    environment {
        SCM_URL = ""
        CREDS_ID = ""
    }
    agent {
        docker {
            image 'maven:3-alpine'
            args '-u root -v /tmp:/tmp -v $HOME/.m2:/root/.m2'
            reuseNode true
            // executes on an executor with the label 'some-label' or 'docker'
            //label "some-label || docker"
        }
    }
    stages {
        stage("Check_java_version") {
            steps {
                script {
                    try {
                        sh "java -version"
                        currentBuild.result = 'SUCCESS'
                    } catch(Exception err) {
                        currentBuild.result = 'FAILURE'
                        ansiColor('xterm') {
                            echo "\033[1;31mCaught exception: ${err}\033[0m"
                        }
                        throw err
                    }
                    echo "\033[0;31m RESULT: ${currentBuild.result} \033[0m"
                }
            }
        }
        stage("Check_mvn_version") {
            when {
                expression {
                    currentBuild.result != 'FAILURE'
                }
            }
            steps {
                sh "mvn -version"
            }
        }
        stage('Gitlab_get_repo') {
            steps {
                script {
                    if ("${env.GITLAB_PROTOCOL}".toLowerCase() == null) {
                        env.GITLAB_PROTOCOL = 'ssh'
                    }
                    if ("${env.GITLAB_SERVER}".toLowerCase() == null) {
                        env.GITLAB_SERVER = 'gitlab_local_docker'
                    }
                    if ("${env.GITLAB_PROJECT}".toLowerCase() == null) {
                        env.GITLAB_PROJECT = 'java'
                    }
                    if ("${env.REPO_NAME}".toLowerCase() == null) {
                        env.REPO_NAME = 'simple-java-maven-app'
                    }
                    if ("${env.BRANCH_NAME}".toLowerCase() == null) {
                        env.BRANCH_NAME = 'master'
                    }

                    if ("${env.GITLAB_PROTOCOL}".toLowerCase() == 'ssh') {
                        SCM_URL = "git@${env.GITLAB_SERVER}:${env.GITLAB_PROJECT}/${env.REPO_NAME}.git"
                        CREDS_ID = 'gitlab-private-key'
                    }else if ("${env.GITLAB_PROTOCOL}".toLowerCase() == 'http') {
                        SCM_URL = "http://gitlab_local_docker/${env.GITLAB_PROJECT}/${env.REPO_NAME}"
                        CREDS_ID = 'gitlab-login'
                    }else {
                        SCM_URL = "https://${env.GITLAB_SERVER}/${env.GITLAB_PROJECT}/${env.REPO_NAME}"
                        CREDS_ID = 'gitlab-login'
                    }
                }
                checkout([$class: 'GitSCM', branches: [[name: "*/${env.BRANCH_NAME}"]],
                        doGenerateSubmoduleConfigurations: false,
                        extensions: [[$class: 'CloneOption', noTags: false, reference: '', shallow: true]],
                        submoduleCfg: [],
                        userRemoteConfigs: [[credentialsId: CREDS_ID, url: SCM_URL]]])
            }
        }
        stage('Build') {
            steps {
                sh 'mvn -B -DskipTests clean package'
            }
        }
        stage('Test') {
            steps {
                sh 'mvn test'
            }
            post {
                always {
                    junit 'target/surefire-reports/*.xml'
                }
            }
        }
        stage('Deliver') {
            steps {
                sh './jenkins/scripts/deliver.sh'
            }
        }
    }
    post {
        always {
            echo 'This will always run'
        }
        success {
            echo "success"
            // notify users when the Pipeline success
            //mail to: 'team@example.com',
            //    subject: "The Pipeline: ${currentBuild.fullDisplayName} has been finished successfully",
            //    body: "The job ${env.BUILD_URL}"
        }
        failure {
            echo 'failure'
            // notify users when the Pipeline fails
            //mail to: 'team@example.com',
            //    subject: "Failed Pipeline: ${currentBuild.fullDisplayName}",
            //    body: "Something is wrong with ${env.BUILD_URL}",
            //    from: 'xxxx@yyyy.com',
            //    replyTo: 'yyyy@yyyy.com',
        }
        unstable {
            echo 'This will run only if the run was marked as unstable'
        }
        changed {
            echo 'This will run only if the state of the Pipeline has changed'
            echo 'For example, if the Pipeline was previously failing but is now successful'
        }
    }
}

Т.е в данном файле предусмотрена вся логика для создания/сборки проекта. Я предусмотрел сборку проектов, по двум критериям:

• Автосборка проекта по пушу кода в гитлаб репозиторий (Используется master бранч).
• Если нужно собрать проект с другими параметрами, можно выполнить сборку «Build with Parameters».

И так, если кто-то запушит свой код в master-branch, то выполнится автосборка проекта по заданному пайплайну. Как по мне, — это очень логично выполнять все автоматом именно с мастер-ветки. Для остальных сборок (кастомных), можно собрать с некоторыми параметрами, выглядит это вот так:

Вот собственно и все, статья «Автосборка Java проектов через Jenkins в Unix/Linux» завершена.

Я ранее рассказывал как можно установить Jenkins на сервер. Сейчас, я хотел бы поделится своей заметкой по установке Jenkins-а и Jenkins-slave. Я для своего примера, буду использовать Docker + docker-compose чтобы поднять все необходимое. Конечно, это не самый хороший способ сделать отказоустойчевый сервер. Но тем не менее — у меня на маке все работает. Тем более, я настроил данное чудо не для ПРОД-а, а для локальной лабы. Чтобы более поробно изучить дженкинс. Хотелось бы сказать, ребят, если вы будете выбирать между CI/CD — не берите дженкинс (ИМХО). Есть ума других крутых тулов. Я хочу многие из них попробовать и конечно же — написать статейку в виде заметки.

Полезное чтиво:

Установка Jenkins в Unix/Linux

Работа с Jenkins-CLI в Unix/Linux

Установка Docker в Debian’s

Установка Docker в RedHat’s

Установка Docker-compose в Unix/Linux

Установка Jenkins в Unix/Linux

Как я говорил ранее, я буду использовать докер для установки дженкинса. ОС которую я использую — Mac OS X. Многие скажует, да какая разница, ты же запускаешь в докере. Но на самом деле — докер немного по разному работает на разных Unix/Linux ОС. Немного пришлось поплясать с бубном, чтобы зависти все это чудо на маке.

Мой docker-compose.yml файл выглядит следующим образом:

---
version: '3.5'
services:
    gitlab:
        image: gitlab/gitlab-ce:latest
        container_name: gitlab
        hostname: gitlab.local
        labels:
            com.example.description: "Accounting webapp"
        ports:
            - "443:443"
            - "80:80"
            - "2222:22"
        dns:
            - 10.17.0.3
            - 1.1.1.1
            - 74.82.42.42
        volumes:
            - "/usr/local/gitlab/config:/etc/gitlab:rw"
            - "/usr/local/gitlab/logs:/var/log/gitlab:rw"
            - "/usr/local/gitlab/data:/var/opt/gitlab:rw"
        extra_hosts:
            jenkins_local_docker: 172.6.6.20
            socat_container: 172.6.6.2
        restart: always
        environment:
            - GITLAB_OMNIBUS_CONFIG="external_url 'http://gitlab.local:80'; gitlab_rails['gitlab_shell_ssh_port']=2222; gitlab_rails['lfs_enabled'] = true;"
        networks:
            network0:
                ipv4_address: 172.6.6.10
        healthcheck:
            test: ["CMD", "curl", "-f", "http://gitlab.local"]
            interval: 1m30s
            timeout: 10s
            retries: 3
            start_period: 5m
    jenkins:
        image: jenkins/jenkins:latest
        container_name: jenkins
        hostname: jenkins.local
        ports:
            - "8080:8080"
            - "50000:50000"
        dns:
            - 10.17.0.3
            - 1.1.1.1
            - 74.82.42.42
        volumes:
            - "/usr/local/jenkins/data_2:/var/jenkins_home:rw"
            - "/var/run/docker.sock:/var/run/docker.sock:rw"
            - "/usr/local/bin/docker:/bin/docker"
        extra_hosts:
            gitlab_local_docker: 172.6.6.10
            socat_container: 172.6.6.2
        restart: always
        privileged: true
        environment:
            - DOCKER_HOST=tcp://socat:2375
        links:
            - socat
        depends_on:
            - gitlab
        networks:
            network0:
                ipv4_address: 172.6.6.20
        pid: host
    socat:
        image: bpack/socat
        container_name: socat
        hostname: socat_container
        restart: "always"
        privileged: true
        ports:
            - "2375:2375"
        dns:
            - 10.17.0.3
            - 1.1.1.1
            - 74.82.42.42
        command: "TCP4-LISTEN:2375,fork,reuseaddr unix-connect:/var/run/docker.sock"
        volumes:
            - "/var/run/docker.sock:/var/run/docker.sock"
        networks:
            network0:
                ipv4_address: 172.6.6.2
#volumes:
    #docker_socket:
        #driver_opts:
        #   type: none
        #   device:  "/var/run/docker.sock"
        #   o: bind
networks:
  network0:
      ipam:
          driver: default
          config:
              - subnet: 172.6.6.0/24

Кто работает с докер-компос, тот сможет прочитать данный файл и понять в чем дело. Но если кто-то не знает, я немного расскажу на что стоит заострить внимание. И так:

Я данным сервисом запускаю 3 контейнера, — gitlab, jenkins (master) и socat. Gitlab — система управления репозиториями кода для Git. данные конфиг делался универсальным и чтобы он работал в любом месте и на Unix/Linux системах. Если что-то не будет работать, то стоит рассмотреть поле DNS (в данном поле прописаны ДНС-ы которые служат резолвом в самих докер-контейнера. Иногда это уместно, когда на работе или дома используются свои ДНС, а остальные блокируются).

Можно заюзать статью чтобы проверить, какие ДНС-ы используются:

Работа с DNS в Unix/Linux

PS: Для данного поля стоит использовать, ТОЛЬКО 3 DNS ЗАПИСИ, не более! Иначе, они просто не будут работать и моугт сломать контейнер(ы).

Многие посмотрет на «socat» конейнер и спросят, а зачем он тут вообще упал? Так вот, он тут служит перенаправлением данных с порта (2375) на Unix сокет (/var/run/docker.sock). И сново могут полететь вопросы, а зачем?

Да дело в том, что докер-прогеры «не смогли» запилить «docker_opts»/»hosts» переменную в докер под Mac OS X. Данная переменная выполняет собственно аналогичные действия, но нативным спообом. Выглядит это вот так (на стороне Linux):

 DOCKER_OPTS="-H tcp://127.0.0.1:2375 -H unix:///var/run/docker.sock"

Т.е данную команду нужно прописать в конфиг докера, или можно запустить демон следующим образом:

$ sudo docker -H tcp://127.0.0.1:2375 -H unix:///var/run/docker.sock -d 

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

На все это дело, я потратил около 7 часов времени и мне не очень было понятно почему не работает. Но в интернете нашелся пример моего бедствия. Я взял идею и опробовал ее — костыльненько, но а что поделать!

Самое интересно, то, что я в своей реализации заюзал «Docker in Docker», т.е пробросил Docker с Mac OS X на Docker хост с jenkins. Иначе , я хз как это должно работать. Если кто-то знает — расскажите

Собственно, gitlab + jenkins — готовы к использованию. Перейдем к настройке jenkins-slave.

Установка Jenkins-Slave в Unix/Linux

Стоит поставить: Docker Plugin плагин. Я еще ставил — Docker Slaves Plugin плагин, но не понял как он работает. Я покажу какие плагины у меня имеются в дженкинсе, возможно кому-то пригодится, но для начала, скачаем CLI для Jenkins:

$ cd ~ && curl 'localhost:8080/jnlpJars/jenkins-cli.jar' > ~/jenkins-cli.jar

Мои установленные плагины:

# java -jar ~/jenkins-cli.jar -s http://localhost:8080/ -auth captain:captain list-plugins
jsch                               JSch dependency plugin                                           0.1.55
ws-cleanup                         Workspace Cleanup Plugin                                         0.37
blueocean-commons                  Common API for Blue Ocean                                        1.10.2
mercurial                          Mercurial plugin                                                 2.5
structs                            Structs Plugin                                                   1.17
jira                               JIRA plugin                                                      3.0.5
sse-gateway                        Server Sent Events (SSE) Gateway Plugin                          1.17
gitlab-oauth                       Gitlab Authentication plugin                                     1.4
conditional-buildstep              Conditional BuildStep                                            1.3.6
greenballs                         Green Balls                                                      1.15
apache-httpcomponents-client-4-api Apache HttpComponents Client 4.x API Plugin                      4.5.5-3.0
subversion                         Subversion Plug-in                                               2.12.1
parameterized-trigger              Parameterized Trigger plugin                                     2.35.2
pipeline-model-extensions          Pipeline: Declarative Extension Points API                       1.3.4.1
build-with-parameters              Build With Parameters                                            1.4
external-monitor-job               External Monitor Job Type Plugin                                 1.7
kubernetes                         Kubernetes plugin                                                1.14.3
workflow-aggregator                Pipeline                                                         2.6
mailer                             Mailer Plugin                                                    1.23
git                                Git plugin                                                       4.0.0-rc
handy-uri-templates-2-api          Handy Uri Templates 2.x API Plugin                               2.1.6-1.0
blueocean-jira                     JIRA Integration for Blue Ocean                                  1.10.2
kubernetes-pipeline-steps          Kubernetes :: Pipeline :: Kubernetes Steps                       1.6
command-launcher                   Command Agent Launcher Plugin                                    1.3
workflow-api                       Pipeline: API                                                    2.33
workflow-job                       Pipeline: Job                                                    2.31
ssh-credentials                    SSH Credentials Plugin                                           1.14
authentication-tokens              Authentication Tokens API Plugin                                 1.3
blueocean-rest-impl                REST Implementation for Blue Ocean                               1.10.2
github-branch-source               GitHub Branch Source Plugin                                      2.4.2
htmlpublisher                      HTML Publisher plugin                                            1.18
simple-theme-plugin                Simple Theme Plugin                                              0.5.1
javadoc                            Javadoc Plugin                                                   1.4
workflow-cps-global-lib            Pipeline: Shared Groovy Libraries                                2.13
blueocean-web                      Web for Blue Ocean                                               1.10.2
jackson2-api                       Jackson 2 API Plugin                                             2.9.8
ssh-slaves                         SSH Slaves plugin                                                1.29.4
gitlab-plugin                      GitLab Plugin                                                    1.5.11
generic-webhook-trigger            Generic Webhook Trigger Plugin                                   1.52
docker-workflow                    Docker Pipeline                                                  1.17
pipeline-stage-tags-metadata       Pipeline: Stage Tags Metadata                                    1.3.4.1
blueocean-pipeline-scm-api         Pipeline SCM API for Blue Ocean                                  1.10.2
pipeline-milestone-step            Pipeline: Milestone Step                                         1.3.1
credentials                        Credentials Plugin                                               2.1.18
docker-java-api                    Docker API Plugin                                                3.0.14
cloudbees-bitbucket-branch-source  Bitbucket Branch Source Plugin                                   2.4.1
github                             GitHub plugin                                                    1.29.3
lockable-resources                 Lockable Resources plugin                                        2.4
jquery-detached                    JavaScript GUI Lib: jQuery bundles (jQuery and jQuery UI) plugin 1.2.1
blueocean-personalization          Personalization for Blue Ocean                                   1.10.2
workflow-scm-step                  Pipeline: SCM Step                                               2.7
ansicolor                          AnsiColor                                                        0.6.2
matrix-auth                        Matrix Authorization Strategy Plugin                             2.3
matrix-project                     Matrix Project Plugin                                            1.13
pipeline-stage-step                Pipeline: Stage Step                                             2.3
pipeline-build-step                Pipeline: Build Step                                             2.7
antisamy-markup-formatter          OWASP Markup Formatter Plugin                                    1.5
pipeline-maven                     Pipeline Maven Integration Plugin                                3.6.7
pipeline-input-step                Pipeline: Input Step                                             2.9
ant                                Ant Plugin                                                       1.9
bouncycastle-api                   bouncycastle API Plugin                                          2.17
handlebars                         JavaScript GUI Lib: Handlebars bundle plugin                     1.1.1
blueocean                          Blue Ocean                                                       1.10.2
pipeline-github-lib                Pipeline: GitHub Groovy Libraries                                1.0
variant                            Variant Plugin                                                   1.1
momentjs                           JavaScript GUI Lib: Moment.js bundle plugin                      1.1.1
blueocean-jwt                      JWT for Blue Ocean                                               1.10.2
plain-credentials                  Plain Credentials Plugin                                         1.5
docker-commons                     Docker Commons Plugin                                            1.13
docker-plugin                      Docker plugin                                                    1.1.5
git-client                         Git client plugin                                                3.0.0-rc
timestamper                        Timestamper                                                      1.8.10
gradle                             Gradle Plugin                                                    1.30
pipeline-rest-api                  Pipeline: REST API Plugin                                        2.10
workflow-basic-steps               Pipeline: Basic Steps                                            2.14
github-api                         GitHub API Plugin                                                1.95
blueocean-i18n                     i18n for Blue Ocean                                              1.10.2
ldap                               LDAP Plugin                                                      1.20
blueocean-events                   Events API for Blue Ocean                                        1.10.2
blueocean-core-js                  Blue Ocean Core JS                                               1.10.2
maven-plugin                       Maven Integration plugin                                         3.2
oki-docki                          oki-docki                                                        1.1
blueocean-config                   Config API for Blue Ocean                                        1.10.2
blueocean-github-pipeline          GitHub Pipeline for Blue Ocean                                   1.10.2
kubernetes-credentials             Kubernetes Credentials Plugin                                    0.4.0
credentials-binding                Credentials Binding Plugin                                       1.17
pipeline-model-definition          Pipeline: Declarative                                            1.3.4.1
config-file-provider               Config File Provider Plugin                                      3.5
pipeline-stage-view                Pipeline: Stage View Plugin                                      2.10
token-macro                        Token Macro Plugin                                               2.6
blueocean-display-url              Display URL for Blue Ocean                                       2.2.0
workflow-multibranch               Pipeline: Multibranch                                            2.20
script-security                    Script Security Plugin                                           1.51
git-server                         GIT server Plugin                                                1.7
pipeline-model-declarative-agent   Pipeline: Declarative Agent API                                  1.1.1
workflow-step-api                  Pipeline: Step API                                               2.19
run-condition                      Run Condition Plugin                                             1.2
pipeline-graph-analysis            Pipeline Graph Analysis Plugin                                   1.9
blueocean-git-pipeline             Git Pipeline for Blue Ocean                                      1.10.2
pipeline-model-api                 Pipeline: Model API                                              1.3.4.1
jenkins-design-language            Design Language                                                  1.10.2
disk-usage                         disk-usage plugin                                                0.28
windows-slaves                     WMI Windows Agents Plugin                                        1.4
workflow-cps                       Pipeline: Groovy                                                 2.63
blueocean-autofavorite             Autofavorite for Blue Ocean                                      1.2.3
workflow-durable-task-step         Pipeline: Nodes and Processes                                    2.29
email-ext                          Email Extension Plugin                                           2.63
branch-api                         Branch API Plugin                                                2.1.2
jdk-tool                           JDK Tool Plugin                                                  1.2
cloudbees-folder                   Folders Plugin                                                   6.7
blueocean-pipeline-editor          Blue Ocean Pipeline Editor                                       1.10.2
blueocean-dashboard                Dashboard for Blue Ocean                                         1.10.2
docker-slaves                      Docker Slaves Plugin                                             1.0.7
durable-task                       Durable Task Plugin                                              1.29
github-oauth                       GitHub Authentication plugin                                     0.31
junit                              JUnit Plugin                                                     1.26.1
pam-auth                           PAM Authentication plugin                                        1.4
pubsub-light                       Pub-Sub "light" Bus                                              1.12
scm-api                            SCM API Plugin                                                   2.3.0
blueocean-pipeline-api-impl        Pipeline implementation for Blue Ocean                           1.10.2
ace-editor                         JavaScript GUI Lib: ACE Editor bundle plugin                     1.1
display-url-api                    Display URL API                                                  2.3.0
workflow-support                   Pipeline: Supporting APIs                                        3.2
locale                             Locale plugin                                                    1.4
resource-disposer                  Resource Disposer Plugin                                         0.12
blueocean-rest                     REST API for Blue Ocean                                          1.10.2
gitlab-merge-request-jenkins       Gitlab Merge Request Builder                                     2.0.0
cloudbees-disk-usage-simple        CloudBees Disk Usage Simple Plugin                               0.9
build-timeout                      Build Timeout                                                    1.19
favorite                           Favorite                                                         2.3.2
blueocean-bitbucket-pipeline       Bitbucket Pipeline for Blue Ocean                                1.10.2
mapdb-api                          MapDB API Plugin                                                 1.0.9.0

После того как плагины поставились, открываем дженкинс и переходим:

«Manage Jenkins» -> «Configure System» и ищем поле «Cloud»:

Кликаем по «Docker Cloud Details» чтобы ввести необходимые данные:

Задаем имя, у меня это — Docker. В поле «Docker Host URI» прописываем хост и порт который юзает докер. У меня — «tcp://172.6.6.2:2375». Почему-то, не прокатило использование хостнейма от соката в этом случае. Может исправлю попозже или на крайний случай — можно оставить как есть, т.к эта лаба служит в качестве примера. Стоит отметить, если у вас используется авторизация к докер хосту, то стоит заполнить «Server credentials». Если нажать на «Advanced», то выпадет список дополнительных параметров которые можно заполить тоже:

Нажмите на «Test connection» чтобы получить тестовое подключение (чтобы убедится что коннекшен работает как нужно).

Идем дальше, клацаем по «DOCKER AGENT TEMPLATES…» Я привел к виду:

Заполнил поле и лейблу как мне угодно. В поле «Docker image» я прописал Jenkins-Slave образ, который я взял с официального докер-регистра — «jenkinsci/slave». Так же, по необходимости заполните все необходимые поля (креденшелы, дополнительные опции).

Первый билд (джоба) на Jenkins-е

Создаем проект под свои нужды. Потом, создаем «Pipeline» проект, например:

Нажимаем на «OK» и сейчас создадим все необходимое.

Находим «Run the build inside Docker containers» и ставим чекбокс. В поле «Docker Image» ставим наш образ, у меня — «jenkinsci/jnlp-slave:latest». Так же, можно прописать «Advanced settings» опции и выставить использовании по памяти. У меня все имеет вид:

Идем дальше, находим «Pipeline» вкладку и заполняем ее под свои нужды. У меня все приведено и имеет вид:

Т.е я заюзал свой гитлаб сервер. В нем есть репозиторий с проектом. Так же, добавил подключение к гитлабу. Собственно, все готово, можно нажимать на «SAVE»!

Слева вверху, нажимаем на «Build Now» и смотрим что получилось!

Если открыть «Manage Jenkins» -> «Manage Nodes», то появится jenkins-slave:

Видно что поднялся слейв и запустил джобу. Можно открыть ее и поглядеть статус выполнения:

Я думаю что на этом пока все, статья «Установка Jenkins и Jenkins-slave в Unix/Linux» завершена.

Года 4 назад, я пытался использовать дженкинс для CI/CD. Но честно говоря, он мне не зашел вообще (по некоторым причинам). Ни для кого не секрет, что данное ПО, используется в 90% случаях не только где я работаю, но и в целом мире (хотя еть много других, крутых альтернатив). Мои друзья и колеги знают как я к нему отношусь, но работа — есть работа, нужно юзать дженкинс на проекте как бы я этого не хотел…

Как по мне, дженкинс очень сырой чтобы его юзать в ПРОД-е и данная технология была прорывным решением тех времен, но не сейчас! Почему я так думаю? Да собственно статья будет об этом. Разрабы не додумались написать стандартное решение для переключения языка. «Удобненько»! Решение конечно есть — это заюзать плагин (конечно, может у разработчиков другой взгляд и они все плагинами дополняют, но я не думаю что это уместно при этом примере). Но честно говоря — это хрень, а не решение как по мне. Ну да ладно, мне надоело терпеть полу-перевод страниц в дженкинсе и хочу юзать чисто анг яз — будет лучше, чем половина ломаного русского языка который дженкинс берет с настроек браузера.

Ну, собственно нам потребуется «Locale Plugin» плагин. Чтобы его установить, перейдите:

«Manage Jenkins» -> «Manage Plugins» и переходим во вкладку «Available». В поле «Filter» вводим название плагина, в данном случае — это «Locale plugin». Нажимаем установить, ставим и перезапускаем дженкинс для того, чтобы он начал работать.

Плагин поставили, теперь открываем «Manage Jenkins» -> «Configure System» и находим «Locale» секцию. В поле «Default Language» нужно прописать язык, например «en_US»:

Вот собсвенно и все решение. Поставил нативный, английский язык и даже очень доволен.

А на этом, у меня все, статья «Настройка языка в Jenkins» завершена.

Работа с CloudFlare и Terraform в Unix/Linux

CloudFlare – это сервис по обслуживанию и обеспечению безопасности, который мы предоставляем своим клиентам. В среднем, сайт с CloudFlare загружается вдвое быстрее, потребляет на 60% меньше трафика, получает на 65% меньше нагрузки на сервер и при этом является более защищенным.

Установка terraform в Unix/Linux

Установка крайне примитивная и я описал как это можно сделать тут:

Установка terraform в Unix/Linux

Так же, в данной статье, я создал скрипт для автоматической установки данного ПО. Он был протестирован на CentOS 6/7, Debian 8 и на Mac OS X. Все работает должным образом!

Чтобы получить помощь по использованию команд, выполните:

$ terraform --help
Usage: terraform [--version] [--help] <command> [args]

The available commands for execution are listed below.
The most common, useful commands are shown first, followed by
less common or more advanced commands. If you're just getting
started with Terraform, stick with the common commands. For the
other commands, please read the help and docs before usage.

Common commands:
    apply              Builds or changes infrastructure
    console            Interactive console for Terraform interpolations
    destroy            Destroy Terraform-managed infrastructure
    env                Workspace management
    fmt                Rewrites config files to canonical format
    get                Download and install modules for the configuration
    graph              Create a visual graph of Terraform resources
    import             Import existing infrastructure into Terraform
    init               Initialize a Terraform working directory
    output             Read an output from a state file
    plan               Generate and show an execution plan
    providers          Prints a tree of the providers used in the configuration
    push               Upload this Terraform module to Atlas to run
    refresh            Update local state file against real resources
    show               Inspect Terraform state or plan
    taint              Manually mark a resource for recreation
    untaint            Manually unmark a resource as tainted
    validate           Validates the Terraform files
    version            Prints the Terraform version
    workspace          Workspace management

All other commands:
    debug              Debug output management (experimental)
    force-unlock       Manually unlock the terraform state
    state              Advanced state management

Приступим к использованию!

Работа с CloudFlare и Terraform в Unix/Linux

У меня есть папка terraform, в ней у меня будут лежать провайдеры с которыми я буду работать. Т.к в этом примере я буду использовать AWS, то создам данную папку и перейду в нее. Далее, в этой папке, стоит создать:

$ mkdir examples modules

В папке examples, я буду хранить так званые «плейбуки» для разварачивания различных служб, например — zabbix-server, grafana, web-серверы и так далее. В modules директории, я буду хранить все необходимые модули.

Начнем писать модуль, но для этой задачи, я создам папку:

$  mkdir modules/cloudflare_record

Переходим в нее:

$ cd modules/cloudflare_record

Открываем файл:

$ vim cloudflare_record.tf

В данный файл, вставляем:

#---------------------------------------------------
# Add a record to the domain
#---------------------------------------------------
resource "cloudflare_record" "record" {
    count   = "${var.domain !="" && var.name !="" && var.value !="" ? 1 : 0}"

    domain      = "${var.domain}"
    name        = "${var.name}"
    value       = "${var.value}"
    type        = "${var.type}"
    ttl         = "${var.ttl}"
    priority    = "${var.priority}"
    proxied     = "${var.proxied}"
}

Открываем файл:

$ vim variables.tf

И прописываем:

#-----------------------------------------------------------
# Global or/and default variables
#-----------------------------------------------------------
variable "name" {
    description = " The name of the record"
    default     = "cloudflare_name"
}

variable "domain" {
    description = "The domain to add the record to"
    default     = ""
}

variable "value" {
    description = "The value of the record. Ex: 192.168.13.113"
    default     = ""
}

variable "type" {
    description = "The type of the record"
    default     = "A"
}

variable "ttl" {
    description = "The TTL of the record"
    default     = 3600
}

variable "priority" {
    description = "The priority of the record"
    default     = "1"
}

variable "proxied" {
    description = "Whether the record gets Cloudflare's origin protection."
    default     = ""
}

Собственно в этом файле храняться все переменные. Спасибо кэп!

Открываем последний файл:

$ vim outputs.tf

И в него вставить нужно следующие строки:

output "record_ids" {
    description = ""
    value       = "${cloudflare_record.record.*.id}"
}

output "record_names" {
    description = ""
    value       = "${cloudflare_record.record.*.name}"
}

output "record_values" {
    description = ""
    value       = "${cloudflare_record.record.*.value}"
}

output "record_types" {
    description = ""
    value       = "${cloudflare_record.record.*.type}"
}

output "record_ttls" {
    description = ""
    value       = "${cloudflare_record.record.*.ttl}"
}

output "record_prioritys" {
    description = ""
    value       = "${cloudflare_record.record.*.priority}"
}

output "record_hostnames" {
    description = ""
    value       = "${cloudflare_record.record.*.hostname}"
}

output "record_proxieds" {
    description = ""
    value       = "${cloudflare_record.record.*.proxied}"
}

Переходим теперь в папку aws/examples и создадим еще одну папку для проверки написанного чуда:

$ mkdir cloudflare_record && cd $_

Внутри созданной папки открываем файл:

$ vim main.tf

И вставим в него следующий код:

#
# MAINTAINER Vitaliy Natarov "vitaliy.natarov@yahoo.com"
#
terraform {
  required_version = "> 0.9.0"
}
provider "cloudflare" {
    email = ""
    token = ""
}
module "cloudflare_record" {
    source                          = "../../modules/cloudflare_record"
    name                            = "cloudflare_record"
}

В файле стоит прописать все необходимое, но самое главное:

• email — Мыло при регистрации аккаунта в клаудфлюре.
• token — Сгенерированный токен от клаудфлюра.

Еще полезности:

Работа с AWS IAM и Terraform в Unix/Linux

Работа с AWS VPC и Terraform в Unix/Linux

Работа с AWS S3 и Terraform в Unix/Linux

Работа с AWS EC2 и Terraform в Unix/Linux

Работа с AWS ASG(auto scaling group) и Terraform в Unix/Linux

Работа с AWS ELB и Terraform в Unix/Linux

Работа с AWS Route53 и Terraform в Unix/Linux

Работа с AWS RDS и Terraform в Unix/Linux

Работа с AWS SNS и Terraform в Unix/Linux

Работа с AWS SQS и Terraform в Unix/Linux

Работа с AWS KMS и Terraform в Unix/Linux

Работа с AWS NLB и Terraform в Unix/Linux

Работа с AWS CloudWatch и Terraform в Unix/Linux

Работа с AWS ALB и Terraform в Unix/Linux

Работа с AWS MQ broker и Terraform в Unix/Linux

Работа с AWS EFS и Terraform в Unix/Linux

Работа с AWS elasticache и Terraform в Unix/Linux

Все уже написано и готово к использованию. Ну что, начнем тестирование. В папке с вашим плейбуком, выполняем:

$ terraform init

Этим действием я инициализирую проект. Затем, подтягиваю модуль:

$ terraform get

PS: Для обновление изменений в самом модуле, можно выполнять:

$ terraform get -update

Проверим валидацию:

$ terraform validate

Запускем прогон:

$ terraform plan

Мне вывело что все у меня хорошо и можно запускать деплой:

$ terraform apply

Как видно с вывода, — все прошло гладко! Чтобы удалить созданное творение, можно выполнить:

$ terraform destroy

Весь материал аплоаджу в github аккаунт для удобства использования:

$ git clone https://github.com/SebastianUA/terraform.git

Вот и все на этом. Данная статья «Работа с CloudFlare и Terraform в Unix/Linux» завершена.