В рейтинге участвует:

групп:

каналов:

Виртуальный сервер на SSD - недорого!

Аренда выделенных и виртуальных серверов (VDS/VPS), хостинг, аренда IP-адресов, администрирование, круглосуточная поддержка

qwarta.ru подробнее

Резервное копирование с проверкой на вирусы!!!

Удобный сервис создания резервных копий на любой сервер сети интернет. Отслеживайте изменения, проверяйте на вирусы. Надежно защитите свой бизнес!

go.backupland.com

Выбираете сервер? Любая конфигурация на заказ!

Аренда физических серверов любых конфигураций под любые запросы - 1С бухгалтерия, игровые сервера, нагруженные проекты, интернет-магазины!

qwarta.ru подробнее

Size: a a a

DevOps

1311 membersпожаловаться на группу
2020 May 28

AA

Andrey A in DevOps
Доброе утро. Есть агент CI (агент запущен в докере), которому надо ходить в приватные репозитории (по ssh). Каким образом наиболее правильно пробросить ему приватный ключ?
Возможные варианты:
- пробрасывать приватный ключ с хостовой системы (он там уже есть), подходит в текущем варианте (пока все агенты на одном хосте), но в перспективе - плохо (планируется часть агентов вынести на др. сервера)
- "зашивать" приватный ключ при сборке докер образа агента (COPY)
- недавно подняли vault, пока сильно не эксплуатируем. Его использовать выглядит наиболее правильно.

Вариант с vault: при сборке образа с агентом CI или же уже при старте контейнера с агентом дополнительно указывать нечто такое:
при старте контейнера:
docker run --rm -e vault_token=Secret_token -e vault_adress=https://vault.test.ru -it debian:stretch bash
 
mkdir ~/.ssh/ && curl -s -H "X-Vault-Token: $vault_token" -X GET $vault_adress/v1/private_ssh_keys/user_1 | jq -r '.data.user_1' > ~/.ssh/id_rsa && chmod 600 ~/.ssh/id_rsa
или при сборке:
Dockerfile:
...
RUN apt-get update && apt-get install -y curl jq openssh-client git
RUN mkdir ~/.ssh/ && curl -s -H "X-Vault-Token: Jdn3j22d..." -X GET https://vault.test.ru/v1/private_ssh_keys/user_1 | jq -r '.data.user_1' > ~/.ssh/id_rsa && chmod 600 ~/.ssh/id_rsa

Сразу ремарка - CI не от гитлаба (да, там чуть удобней, что агент сразу имеет доступ к репо, паплайн которого был запущен при коммите)
Вопрос: как правильнее сделать/делается?
источник
10:16пожаловаться#1

DS

Dmitry Sergeev in DevOps
Andrey A
Доброе утро. Есть агент CI (агент запущен в докере), которому надо ходить в приватные репозитории (по ssh). Каким образом наиболее правильно пробросить ему приватный ключ?
Возможные варианты:
- пробрасывать приватный ключ с хостовой системы (он там уже есть), подходит в текущем варианте (пока все агенты на одном хосте), но в перспективе - плохо (планируется часть агентов вынести на др. сервера)
- "зашивать" приватный ключ при сборке докер образа агента (COPY)
- недавно подняли vault, пока сильно не эксплуатируем. Его использовать выглядит наиболее правильно.

Вариант с vault: при сборке образа с агентом CI или же уже при старте контейнера с агентом дополнительно указывать нечто такое:
при старте контейнера:
docker run --rm -e vault_token=Secret_token -e vault_adress=https://vault.test.ru -it debian:stretch bash
 
mkdir ~/.ssh/ && curl -s -H "X-Vault-Token: $vault_token" -X GET $vault_adress/v1/private_ssh_keys/user_1 | jq -r '.data.user_1' > ~/.ssh/id_rsa && chmod 600 ~/.ssh/id_rsa
или при сборке:
Dockerfile:
...
RUN apt-get update && apt-get install -y curl jq openssh-client git
RUN mkdir ~/.ssh/ && curl -s -H "X-Vault-Token: Jdn3j22d..." -X GET https://vault.test.ru/v1/private_ssh_keys/user_1 | jq -r '.data.user_1' > ~/.ssh/id_rsa && chmod 600 ~/.ssh/id_rsa

Сразу ремарка - CI не от гитлаба (да, там чуть удобней, что агент сразу имеет доступ к репо, паплайн которого был запущен при коммите)
Вопрос: как правильнее сделать/делается?
надо ходить в приватные репозитории при сборке образа или после запуска контейнера из этого образа?
источник
10:29пожаловаться#2

AA

Andrey A in DevOps
после, когда джобы уже будут запускаться
источник
10:29пожаловаться#3

DS

Dmitry Sergeev in DevOps
Andrey A
после, когда джобы уже будут запускаться
этот контейнер как агент CI используется?
источник
10:30пожаловаться#4

AA

Andrey A in DevOps
да, стартует контейнер с установленным агентом CI
источник
10:32пожаловаться#5

DS

Dmitry Sergeev in DevOps
Andrey A
да, стартует контейнер с установленным агентом CI
Я бы юзал возможности CI.
Скачиваешь все что нужно через CI, ключи брать из секретов (из vault, или из самой CI (у многих есть хранилище секертов встроенное))
Не вижу смысла зашивать их в образ
источник
10:32пожаловаться#6

DS

Dmitry Sergeev in DevOps
Andrey A
Доброе утро. Есть агент CI (агент запущен в докере), которому надо ходить в приватные репозитории (по ssh). Каким образом наиболее правильно пробросить ему приватный ключ?
Возможные варианты:
- пробрасывать приватный ключ с хостовой системы (он там уже есть), подходит в текущем варианте (пока все агенты на одном хосте), но в перспективе - плохо (планируется часть агентов вынести на др. сервера)
- "зашивать" приватный ключ при сборке докер образа агента (COPY)
- недавно подняли vault, пока сильно не эксплуатируем. Его использовать выглядит наиболее правильно.

Вариант с vault: при сборке образа с агентом CI или же уже при старте контейнера с агентом дополнительно указывать нечто такое:
при старте контейнера:
docker run --rm -e vault_token=Secret_token -e vault_adress=https://vault.test.ru -it debian:stretch bash
 
mkdir ~/.ssh/ && curl -s -H "X-Vault-Token: $vault_token" -X GET $vault_adress/v1/private_ssh_keys/user_1 | jq -r '.data.user_1' > ~/.ssh/id_rsa && chmod 600 ~/.ssh/id_rsa
или при сборке:
Dockerfile:
...
RUN apt-get update && apt-get install -y curl jq openssh-client git
RUN mkdir ~/.ssh/ && curl -s -H "X-Vault-Token: Jdn3j22d..." -X GET https://vault.test.ru/v1/private_ssh_keys/user_1 | jq -r '.data.user_1' > ~/.ssh/id_rsa && chmod 600 ~/.ssh/id_rsa

Сразу ремарка - CI не от гитлаба (да, там чуть удобней, что агент сразу имеет доступ к репо, паплайн которого был запущен при коммите)
Вопрос: как правильнее сделать/делается?
Как правило в CI не надо делать так: docker run --rm -e vault_token=Secret_token -e vault_adress=https://vault.test.ru -it debian:stretch bash

Многие CI умеют использовать контейнер как агент. Запускают контейнер, и уже внутри все выполняют как в обычном агенте. В том числе можно юзать стандартный DSL CI системы, для скачивания того что тебе нужно и использования секретов
источник
10:36пожаловаться#7

DS

Dmitry Sergeev in DevOps
Andrey A
Доброе утро. Есть агент CI (агент запущен в докере), которому надо ходить в приватные репозитории (по ssh). Каким образом наиболее правильно пробросить ему приватный ключ?
Возможные варианты:
- пробрасывать приватный ключ с хостовой системы (он там уже есть), подходит в текущем варианте (пока все агенты на одном хосте), но в перспективе - плохо (планируется часть агентов вынести на др. сервера)
- "зашивать" приватный ключ при сборке докер образа агента (COPY)
- недавно подняли vault, пока сильно не эксплуатируем. Его использовать выглядит наиболее правильно.

Вариант с vault: при сборке образа с агентом CI или же уже при старте контейнера с агентом дополнительно указывать нечто такое:
при старте контейнера:
docker run --rm -e vault_token=Secret_token -e vault_adress=https://vault.test.ru -it debian:stretch bash
 
mkdir ~/.ssh/ && curl -s -H "X-Vault-Token: $vault_token" -X GET $vault_adress/v1/private_ssh_keys/user_1 | jq -r '.data.user_1' > ~/.ssh/id_rsa && chmod 600 ~/.ssh/id_rsa
или при сборке:
Dockerfile:
...
RUN apt-get update && apt-get install -y curl jq openssh-client git
RUN mkdir ~/.ssh/ && curl -s -H "X-Vault-Token: Jdn3j22d..." -X GET https://vault.test.ru/v1/private_ssh_keys/user_1 | jq -r '.data.user_1' > ~/.ssh/id_rsa && chmod 600 ~/.ssh/id_rsa

Сразу ремарка - CI не от гитлаба (да, там чуть удобней, что агент сразу имеет доступ к репо, паплайн которого был запущен при коммите)
Вопрос: как правильнее сделать/делается?
А что за CI то?
источник
10:37пожаловаться#8

AA

Andrey A in DevOps
bamboo
источник
10:37пожаловаться#9

DS

Dmitry Sergeev in DevOps
Andrey A
bamboo
Это платное поделие от atlassian не умеет контейнеры юзать как агенты? Приходится делать docker run, docker exec, docker exec, ..., ?
источник
10:38пожаловаться#10

DS

Dmitry Sergeev in DevOps
Andrey A
bamboo
Хотя вроде умеет: https://confluence.atlassian.com/bamboo/docker-runner-946020207.html
источник
10:41пожаловаться#11

AA

Andrey A in DevOps
недавно обновились до версии 2018 года (6.5.1), да, там появилась опция агентов в докере. Но пока не узнал, что это дает. Видимо надо смотреть.
Да, сейчас собираем в докере агентов самостоятельно
источник
10:41пожаловаться#12

DS

Dmitry Sergeev in DevOps
Andrey A
недавно обновились до версии 2018 года (6.5.1), да, там появилась опция агентов в докере. Но пока не узнал, что это дает. Видимо надо смотреть.
Да, сейчас собираем в докере агентов самостоятельно
мда, хорошо что мне удалось в свое время отбиться от менеджера, который пытался bamboo пропихнуть. Ладно бы это еще бесплатно было
источник
10:43пожаловаться#13

AA

Andrey A in DevOps
ну да, CI от gitlab легче заходит, там как-то это всё логичнее...
источник
10:44пожаловаться#14

DS

Dmitry Sergeev in DevOps
Andrey A
ну да, CI от gitlab легче заходит, там как-то это всё логичнее...
В bamboo DSL на чистом Java? В доках нашел примеры pipeline as code:

import com.atlassian.bamboo.specs.api.builders.plan.Plan;
import com.atlassian.bamboo.specs.api.util.EntityPropertiesBuilders;
import org.junit.Test;

public class MyPlanTest {
    @Test
    public void testMyPlan() {
        final Plan myPlan = ...;

        // if validation fails, an exception will be thrown
        EntityPropertiesBuilders.build(myPlan);
    }
}


Жесть, а все еще ругаются на groovy в Jenkins
источник
10:44пожаловаться#15

AA

Andrey A in DevOps
хз, кпочками там все накликивают разработчики, в качестве таска обычно просто указывают некий shell script
источник
10:46пожаловаться#16

DS

Dmitry Sergeev in DevOps
Andrey A
хз, кпочками там все накликивают разработчики, в качестве таска обычно просто указывают некий shell script
оу. беда какая. Лучше bamboo не стал с тех пор
источник
10:47пожаловаться#17

AA

Andrey A in DevOps
ну тут типа зато удобство что всё нативно связано - jira, bitbucket. crowd, bamboo, confluence
источник
10:48пожаловаться#18

DS

Dmitry Sergeev in DevOps
Andrey A
ну да, CI от gitlab легче заходит, там как-то это всё логичнее...
пора мигрировать с bamboo ))). А во сколько он обходится кстати?
источник
10:48пожаловаться#19

AA

Andrey A in DevOps
бесплатно)
источник
10:48пожаловаться#20