ci/cd статики с помощью jenkins + docker

у тебя докер отсутствия головного мозга

Я готов рассмотреть и другие варианты без docker/jenkins

у тебя падает jenkins — ты не видишь варианта кроме как засунуть его в docker

у тебя нет CI/CD, а есть только jenkins, который деплоит в продакшн — ты видишь проблему в том, что твой код не в docker'е

у тебя нет представления о том, что такое jenkins и как работать с docker'ом, но ты видишь решение либо в связке jenkins/docker либо в её отсутствии.

я хз, чем тебе помочь

у тебя падает jenkins — ты не видишь варианта кроме как засунуть его в docker

Он падает локально у разработчика с windows - поставить себе его в таком-же виде на macOS / на сервер linux я не могу. Это затрудняет процесс фикса его проблем

у тебя нет CI/CD, а есть только jenkins, который деплоит в продакшн — ты видишь проблему в том, что твой код не в docker'е

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

у тебя нет представления о том, что такое jenkins и как работать с docker'ом, но ты видишь решение либо в связке jenkins/docker либо в её отсутствии.

Но я с этим и не спорил «У меня опыта в devOps ноль». Я думаю что есть решение с jenkins+docker (но я его не вижу полностью), но готов рассмотреть и другие варианты

поставить себе его в таком-же виде на macOS / на сервер linux я не могу

поверь мне, тут проблема не в jenkins'e и не в отсутствии docker'а

можно более четкие советы, а не философский троллинг?)

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

2. если у тебя падает сам по себе jenkins — докер твою проблему не решит, с вероятностью в 99.999% он будет так же падать и в докере. см. пункт 1

3. от того, что ты прямо сейчас обернешь свой код в docker — лучше не станет вообще никому. во-первых потому, что ты понятия не имеешь, как это делать. во-вторых потому, что ты понятия не имеешь, что сборка докер-образа в jenkins'е — это то же самое, что сборка докер-образа руками, только в jenkins'e, как и все остальные операции. в-третьих, потому что если ты не деплоишь на продакшн контейнеры, на тестовом стенде от них толку нет. в-четвертых, потому что у тебя нет тестового стенда в принципе.

совет простой — выбрось из своей головы маркетинговый булшит, загугли, как установить jenkins, установи его на ту машину, которая тебе больше понравится хоть докером хоть bat-файлом, настрой его так, чтобы он не падал. выдели инстанс под тестовый стенд и задеплой туда свой «финальный код», который ты сможешь проверить до деплоя в продакшн. настрой деплой в продакшн не по коммиту в мастер, а по пройденным автотестам (хотя бы). и вот когда у тебя все это будет работать хотя бы в таком виде — начинай заикаться о том, что у тебя есть CI/CD и что возможно тебе нужен докер.

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

Так понятно что не мешает, и понятно что в докере его также нужно будет настраивать. Проблема в том что сейчас я его настрою у себя на macOS - а потом захочу перейти на линукс/виндовс/развенуть докер на сервере -и не смогу, придется заново настраивать. Плюс в случае с докером я могу использовать git (?) чтоб хранить все настройки jenkins и в случае потери данных (например сломается ssd) не заниматься и не вспоминать а как именно я его настраивал раньше.

если у тебя падает сам по себе jenkins — докер твою проблему не решит, с вероятностью в 99.999% он будет так же падать и в докере. см. пункт 1

Зависает, а не падает, иногда на npm run build, иногда на других шагах. Сами шаги же если их просто запускать в консоле всегда работают нормально. Если это воспроизведется на моем машине (хоть и в докере) я смогу хоть попробовать разобраться что происходит.

настрой деплой в продакшн не по коммиту в мастер, а по пройденным автотестам

То я и хочу узнать как это сделать? Как деплоить докер? П.С. я думал что-то типа dev/test/release бранчей сделать, автотестов пока мало.

Или ты/вы предлагаешь (пока) не заморачиватся с докером для финального кода, и не иметь возможность запустить его локально, но иметь два (гугл) сервера (релизный и тестовый) ?

В принципе вариант, но опять же на сервере мне приходится что-то настраивать (например запускал какие-то модули для apache) и я не уверен что у меня сервера будут одинаковые, в результате может получится что на тестовом сервере работает - а на проде нет, я думал докер как раз и призван решить эту проблему, я не прав???

Проблема в том что сейчас я его настрою у себя на macOS - а потом захочу перейти на линукс/виндовс/развенуть докер на сервере -и не смогу, придется заново настраивать.

во-первых, ты скорее всего имел в виду «развернуть дженкинс на сервере». во-вторых, что тебе мешает перенести конфиги с одной машины на другую?

Плюс в случае с докером я могу использовать git (?) чтоб хранить все настройки jenkins и в случае потери данных (например сломается ssd) не заниматься и не вспоминать а как именно я его настраивал раньше.

открою тебе секрет, хранить конфиги в VCS ты можешь прямо сейчас. как мог и раньше.

Зависает, а не падает, иногда на npm run build, иногда на других шагах. Сами шаги же если их просто запускать в консоле всегда работают нормально. Если это воспроизведется на моем машине (хоть и в докере) я смогу хоть попробовать разобраться что происходит.

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

не заморачиватся с докером для финального кода, и не иметь возможность запустить его локально, но иметь два (гугл) сервера (релизный и тестовый) ?

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

То я и хочу узнать как это сделать?

через Conditional BuildStep

Как деплоить докер?

а так же «как собирать приложение в контейнер», «почему мой контейнер не стартует в гуглклауде» и куча других вопросов новичка. тебе надо docker в резюме вписать что ли, что ты так к нему пристал? ну тогда начни с мануалов.

на сервере мне приходится что-то настраивать (например запускал какие-то модули для apache) и я не уверен что у меня сервера будут одинаковые, в результате может получится что на тестовом сервере работает - а на проде нет, я думал докер как раз и призван решить эту проблему

если у тебя уже есть настроенный CI/CD контейнеров в продакшн — да. если у тебя нет опыта, нет вообще ничего для этого — разберись хотя бы с азами CI, когда тебе реально понадобится докер — ты это заметишь.

а задача идентичности тестового окружения решается хранением конфигурации в VCS как части билда, например. и тогда твои наследники не будут бегать как ошпаренные когда твой контейнер перестанет работать, а что в нем не так — хз, у нас этот контейнер всегда работал. или снапшотами виртуалок. или еще кучей способов, и докер в них фигурирует после того и только после того, как деплой на продакшн у тебя юзает контейнеры. у тебя он не юзает контейнеры, у тебя нет опыта с ним — так нахрена ты лезешь всунуть докер (и ставить с ним эксперименты на продакшне) во что бы то ни стало?

Советую посмотреть в сторону Drone CI.

докер в них фигурирует после того и только после того, как деплой на продакшн у тебя юзает контейнеры

Это, в общем, неверно. Использовать докер для тестирования — это один из самых распространённых кейсов.

А вот для деплоя уже нужны инструменты для оркестрации (swarm, k8s) и мониторинга, причём весь конечный пайплайн бывает очень сложно настроить.

во-первых, ты скорее всего имел в виду «развернуть дженкинс на сервере». во-вторых, что тебе мешает перенести конфиги с одной машины на другую?

Да имел в виду дженкинс, так мешает то что они платформо специфичны, например задание переменных окружение Path на линукс/виндовс вроде разное.

И как его вообще перенести? Просто перенести всю директорию с jenkins на другую систему?

открою тебе секрет, хранить конфиги в VCS ты можешь прямо сейчас. как мог и раньше.

Любопытно, спасибо. Но конфиги != полноценный стопроцентный перенос и воспроизводимость.

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

а так же «как собирать приложение в контейнер», «почему мой контейнер не стартует в гуглклауде» и куча других вопросов новичка.

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

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

Ну формально у меня просто сайт статика и я могу запустить https://www.npmjs.com/package/http-server или аналог.

Но это отстой, потому что у меня на сервере apache плюс htaccess который делает ЧПУ (примитивный), а значит мне уже на моей локальной машине нужно настроить это же, плюс второму разработчику на винде настроить это же.

Плюс у меня раньше была проблема когда у апача не было прав на чтение html файлов и была какая-то ошибка, такие проблемы я локально не увижу

То есть еще раз, я хочу самое простое решение которое только может быть, я не девОпс(я фронтенд) и хочу чтоб я такой git push, а оно такое мне в телегу «чувак готово».

Пока что я вижу что все решение сложные/костыльные/напряжные, докер мне показался тем чем нужно, хотя после того что ты мне сказал я тоже вижу что с ним мороки дофигища :(

1) Надо забыть как страшный сон запускать такие вещи как дженкинкс или что-то ещё серверное на иммитаторе ОС. Поставьте дженкинс на сервер с настоящей ОС. Виндовс — это для ценителей на своих рабочих/личных компьютерах

2) рекомендую гитлаб. И гит, и CI, и всё остальное в одном месте. Он хорош

3) настрой CI так: коммитишь в ветку, собирается всё что нужно и деплоится по адресу BRACHNAME.mytestserver.net

Это, в общем, неверно.

это, в общем, единственно верно если нет отдельного (обычно называемого stage) енвайрмента, который повторяет продакшн, в противном случае результатами такого тестирования можно подтереться. и в данном случае его очевидно нет.

то что они платформо специфичны, например задание переменных окружение Path на линукс/виндовс вроде разное

И как его вообще перенести? Просто перенести всю директорию с jenkins на другую систему?

во-первых, необходимость задания переменных path вне глобальных — это само по себе повод задуматься, все ли ты делаешь правильно. во-вторых, ну посмотри ты, что тебе нужно перенести, епт. твой коллега-виндузятник наворотил себе конфиг, с которым джоба падает, что из этого тебе нужно перенести? джобы - можешь скопировать, можешь пересоздать заново, это дело 2х минут. настройки дженкинса? а ты уверен, что ты потащишь нужные? если уверен — копируй config.xml и вперед

конфиги != полноценный стопроцентный перенос и воспроизводимость.

конфиги == полноценный стопроцентный перенос и воспроизводимость если ты знаешь, какими конфигами твое приложение пользуется. если копипастить с so бездумно — тогда да, сложнее

я слышал хорошую аналогию про хороший девОпс

а про то, что хороший девОпс делает хороший девОпс инженер, там не рассказывали? в твоей паршивой аналогии — сантехник

Ну формально у меня просто сайт статика и я могу запустить https://www.npmjs.com/package/http-server или аналог.

мнде. я так понимаю, виртуалки в ваш коровник коворкинг еще не завезли? знаешь, это такие штуки, которые очень похожи на докер, только крякают как продакшн сервер, выглядят как то, что можно прозрачно конфигурировать, плавают как то, что не резетает персистенс когда не надо и не прячут внутри себя curl | sudo bash

я хочу самое простое решение которое только может быть

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

самое простое — упомянутый выше gitlab, скорми ему два енвайрмента и радуйся жизни.

Погоди, я еще не уверен как он устроен, но я так понимаю что я аналогично пропишу ему степы, и если например в нем зависнит npm run build мне будет еще труднее понять в чем дело. Или я не прав?

во-первых, необходимость задания переменных path вне глобальных — это само по себе повод задуматься, все ли ты делаешь правильно.
если ты знаешь, какими конфигами твое приложение пользуется. если копипастить с so бездумно — тогда да, сложнее

Для меня это темный лес, в котором я ОЧЕНЬ потихоньку разбираюсь.

делает хороший девОпс инженер, там не рассказывали

Для меня пока что не ОК по деньгам нанять, в будущем потенциально это и сделаю.

знаешь, это такие штуки, которые очень похожи на докер

В принципе вариант использовать их чтоб протестировать локально, но опять же, я не получу «работает локально» === «работает на проде».

А в случае когда локально и на проде докер я вроде как получу, или я опять ошибся?

Между строк, я плохо знаю цену на девОпс работу. Ты кажешься мне компетентным, сколько ты хочешь за час своей работы со мной?

я хочу самое простое решение которое только может быть

А в идеале еще и «стабильное/корректное/правильное» - имею в виду что «локально работает» === «работает на проде» с максимально возможной вероятностью

Погоди, я еще не уверен как он устроен, но я так понимаю что я аналогично пропишу ему степы, и если например в нем зависнит npm run build мне будет еще труднее понять в чем дело. Или я не прав?

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

А в случае когда локально и на проде докер я вроде как получу, или я опять ошибся?

получишь. но начинать надо с докера в продакшне, а потом уже тащить его в CI. если у тебя есть возможность ставить эксперименты и набивать шишки на pro – вперед

«локально работает» === «работает на проде» с максимально возможной вероятностью

этого не будет, вообще забывай о «локально» для тестирования. тебе нужен еще один енвайрмент, максимально идентичный продакшну. варианты на выбор:

1. такой же инстанс, как и в продакшне, который ты скормишь гитлабу и/или дженкинсу. кастомные конфиги - в VCS, идентичность всего остального тебе обеспечит облако. локально – можешь ковырять перед тестом, можешь сразу выливать все в тест и там уже тестировать.

2. докер, если его правильно приложить к правильному месту, тоже решит эту задачу, но тебе никуда не спрятаться от эффортов на

- изучение докера всеми участниками

- преодоление граблей докера в виндовом окружении (хз, может в последнее время стало полущ, когда я пробовал – все было не очень очевидно)

- добавление еще одной прослойки и связанные с этим грабли

- в случае, если тестовое и продакшн окружение будет крутиться внутри одной машины в разных контейнерах – эффорты на разруливание проблем с этим (я не знаю, как это получается, но при том, что это описано в куче мануалов, неочевидные проблемы вылазят всегда)

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

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

Хорошо, спасибо. Буду изучать gitlab CI, и попробую развернуть в гугле инстанс

У меня вообще вопрос - зачем вам дженкинс если это у вас просто замена крону. Пункт 2 Дженкинс обычно дают QA и лепят туда 5-6 галочек (чуть больше это уже превращается....)

Ну брали с надеждой/залогом на будущее, изначально я думал он может определять когда я комитнул (и по факту он может, но нужно чтоб был запущен не локально), плюс есть разные плагины, например в телеграмм приходит оповещение после релиза.

Но минусов от него было больше, я пожалел что выбрал его