обычно когда секреты проходят через jenkins это выглядит как запихивание паролей в файлы конфигурации. Этот шаг легко заменяется: вместо инструкции "используй пароль 123qwe для базы" пишем инструкцию "возьми пароль для базы из s3://.../../.. (ну или vault, или secret manager)" при этом в инфраструктуре пробрасываем роли для инстансов приложения, чтоб доступ к секретам был. всё остальное, типа обратной связи - не меняется и переход не влияет на общую архитектуру CI/CD

Vault у меня через него

Это все в амазоне?

А в само хранилище ныряет приложение или деплой тулза?

Да. Джекнинс EC2, таргет - сворм на пачке из EC2

автоскейл )

а вообще пока на кубер добро не дают - жрем кактусы как можем

Может проще запоковать в кастомную амишку и задеплоить?

возвращаясь к треду, в той схеме все зашибись кроме одного. Скрипт на таргетах. 1. Его надо обновлять / поддержкивать 2. Его надо своевременно доставлять не пересекаясь с потоками деплоя 3. Часть логики деплоя придется держать в этом-же скрипте, что уменьшает прозрачность

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

Открывать c докера API для дженкинса?

планируется сине-зеленая. Т.к. безшовный деплой в требованиях ТЗ

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

джнкинс закрыть в сеть и дать доступ на уровне фаервола, собственно на дженкинс можно попасть только из впн сети

тут видишь какое дело. желательно чтобы было максимально приближено к проду. А там требования от CISO на всякие контролируемые изменения, чеки на каждом шагу. Поэтому чем меньше таких спорных моментов как открытый/запароленый апи докера (даже внутри ДМЗ), тем лучше

у меня все через волт, все в нем хранится все явки парили и прочее)) со своими полиси и разделением доступа

всеми конечностями "ЗА". Но я не заставлю разрабов привязываться к конкретному решению без веских обоснований. А так приходится самому реализовывать динамику в секретах

интересный факт. У нас пачка разных проектов с негуляющими разрабами. И часть из этих проектов еще просто не созрела для поддержки централизованного хранилища секретов. Им еще запуститься нужно

интересный факт. У нас пачка разных проектов с негуляющими разрабами. И часть из этих проектов еще просто не созрела для поддержки централизованного хранилища секретов. Им еще запуститься нужно

А зачем волт, если есть jenkins credentials plugin?

@pyToshka как владелец уже рабочей схемы с волтом, как считаешь, я не перемудрил?

привет, кто знает хороший ресурс про git hooks на русском (если есть)?

Не ленись, учи инглиш https://git-scm.com/docs/githooks

@pyToshka как владелец уже рабочей схемы с волтом, как считаешь, я не перемудрил?

я было думал гайд как учить

А зачем волт, если есть jenkins credentials plugin?

server { listen 80; server_name *.project.dev.org; location / { proxy_pass http://192.168.1.240:80; proxy_pass_header on; proxy_pass_request_headers on; proxy_pass_request_body on; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_read_timeout 90; } }

прокси - в девопс

Почему нет

все правильно проверил каждый етап дело в нджинкс

server { listen 80; server_name *.project.dev.org; location / { proxy_pass http://192.168.1.240:80; proxy_pass_header on; proxy_pass_request_headers on; proxy_pass_request_body on; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_read_timeout 90; } }

все правильно проверил каждый етап дело в нджинкс

бутал машину?

это вы мне?

или даже это https://askubuntu.com/questions/729100/nginx-reverse-proxy-and-subdomains-on-apache2

proxy_http_version 1.1; Помогло, сенкс