Saboteur

Все приложения должны крутиться в контейнерах. Соответственно Jenkins тоже должен жит в контейнере.

Почему?
Если дженкинс должен УПРАВЛЯТЬ контейнерами, то почему он сам должен крутиться внутри контейнера?
Или задача запускать контейнер в контейнере в контейнере?

Дженкинс в контейнере удобен, если вы запускаете его в кубере, чтобы он себе поднимал в нужный момент агенты и останавливал их. Просто так на хосте делать контейнер для дженкинса - ну можно конечно, но зачем..?
Запустить в контейнере мастер? или агент? Или у вас эксекуторы только на мастере?

Если у вас нет оркестратора, то нет смысла пихать дженкинс в контейнер, а потом изнутри искать выход наружу к папкам и ексекуторам. То есть у вас подход какой-то неправильный.

Ну так неплохая задача. Ставишь где-нить lemp (nginx+mysql), настраиваешь ему конфигурацию, чтобы отдавал метрики и запускал php скрипт, пишешь скрипт который лазит в базу и выдает две строки, подключаешь скрипт к nginx, и упаковываешт это в докерфайл, возможно с доп. файлами.

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

Кубер это оркестратор с достаточно широкими возможностями автоматизации.
Он не имеет смысла если у вас парочка компонентов, которые вы запускаете на одном хосте.

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

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

В третью, большое количество интеграций с внешними системами при помощи раннеров, что позволяет сделать ci/cd, разграничить его по правам и так далее, объединиться с каким-нить hashicorp vault при помощи парочки аннотаций и так далее.

Для сайтов - нет смысла.
Докер для развертывания удобен в случае различных кастомных настроек, установки плагинов и так далее. А банальный nginx+php разворачивается на любой ОС очень быстро.

Мне также очень нравится то, что БД пишет данные в volume, который потом можно сжать и скопировать на другой сервер, а не охреневать когда надо перенести базу на сотни гигов.

Кто мешает выделить отдельный volume для базы данных без всяких докеров?
Это может быть какой угодно volume - раздел, виртуальный диск, рейд, что угодно.

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

IMHO докер вообще для сайтов не лучшее решение. А самое крутое преимущество докер получает вместе с оркестрацией типа kubernetes/openshift, когда десятки и сотни приложений/микросервисов.

Нет, докер не работает с системой на которой установлен. Он использует ее ядро, а дальше - зависит от докер образа.

Странные рассуждения.

например Nginx. Так как в случае с Docker это не означает покупку ещё одного сервера,

И без докера, это не обязательно означает покупку еще одного сервера.

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

На сегодня Docker чаще это просто промежуточный кирпичик по пути в оркестрацию контейнерами кубером или опенщифтом. А в этом плане, гораздо лучше все-таки отталкиваьтся от бест практик, а именно S3 бакет.
Можно рамдиск для аплоад папки из которой отдельный процесс будет перекладывать в s3 с какими-то промежуточными действиями (регистрация в базе, проверка антивирусом, проверка формата файлов, чтобы не битый был)

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

непонятна ваша проблема.
Переводы строк в линукс виде - совершенно корректно.
Логи нормальные, что именно не так, где именно проблема - не указано.
Виндовый блокнот не умеет в линукс перевод строк?
Какая винда? у меня под блокнот нормально все делает
Ну или открывай не блокнотом

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

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

use mybase
db.runCommand( { compact: "mycollectionname" })

service jenkins start

вот на этом моменте нужно найти старт-скрипт дженкинса или его unit файл, и посмотреть что внутри происходит.
Подозреваю, что там тупо лажа с определением как найти запущенный дженкинс. МОжет связано с путаницей местоположения PID файла, или просто кривой скрипт.

Сертификаты не должны быть частью docker image, и должны монтироваться снаружи. Тогда обновление сертификата не будет требовать нового билда продукта.
Прокидывать снаружи их можно через mount
Тогда обновил сертификат на маунте и перезапустил контейнер.
Если жить в кубере/опенщифте - там сертификат можно в секрете хранить и монтировать как файл.

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

В сложном проекте конфигурация может выглядеть так:
Мастер крутится в своем более-менее стабильном контейнере и рулит исключительно задачами, воркеров не запускает.
Есть несколько видов подготовленных контейнеров для слейвов - для сборки и для тестов, с разной конфигурацией. В некоторых случаях можно даже тут сделать разные контейнеры для сборки nodejs, сборки питона, тестов, и например контейнер для performance тестов.
Во время пайплайна нужные шаги выполняются на нужном слейве, а слейвы динамически поднимаются, если очередь вырастает и также автоматически уничтожаются, когда они не нужны. Например если контейнер поднимается за 1-2 минуты, то при простое в 20-30 минут его можно тушить. Так вы и сократите время билдов, когда их много, и сэкономите деньги на ресурсах, когда они простаивают.

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

Что значит "принято". Это зависит от проекта и ваших предпочтений.
Нет явных общепринятых решений, так как одинаковых проектов немного.

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

докер это контейнер для запуска конкретного приложения в определенной среде, а не для запуска операционной системы. Что система будет делать в контейнере? Какой конкретно процесс от системы вы хотите запустить в докере?

Для запуска операционной системы есть виртуальные машины, а докер - в принципе суть заключается в том, что запускается конкретный процесс, в изолированной среде, в текущей ОС.

Docker работает только под Линукс, потому что он работает благодаря namespace и cgroups фич, встроенных в ядро Линукс.
В винде запускается виртуальная машина с Линукс, в которой уже запускается докер.

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

Так как разные Линуксы все равно юзают тоже ядро, то в образах и указано что именно установлено в Линукс, и образ PHP обозначает, что там будет образ линукса с установленным PHP

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

В случае кубера - внешний балансер раскидывает по кластерам, внутренний сервис внутри кластера - уже по подам

База - сама по себе, микросервис - сам по себе.
У базы может быть свой кластер с репликацией базы по своим нодам. У микросервиса - свой кластер, со своими контейнерами. В результате и база и сервис можно горизонтально масштабировать, в зависимости от того, что работает недостаточно быстро.

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

А непосредственно балансировщик - это вообще часть функционала кластера или сетевой подсистемы, а не непосредственно контейнера.