BookStack

https://github.com/Himura2la/MiLight/blob/master/ruby/Mi-Light.txt осталось только это )

Потому что Вы невнимательно читали ¯_(ツ)_/¯

1. Спасибо за утилиту, главная проблема линуксовой экосистемы в том что очень много всего где-то запрятано и крайне сложно узнать, что так вообще можно ))
2. Хорошо, что в Arch всё так просто, а то я его совсем не рассматривал.
3. Так это и есть pulseaudio-module-jack, который я предлагаю использовать при наличии. Спасибо за готовую команду )

Интересно, откуда взялось слово .PHONY?

Эта рекомендация актуальна для сборки проектов, время сборки которых изменяется в минутах или часах (а не в миллисекнудах, как в статье).
Собственно, в реальной жизни обычно так и приходится запускать make -j4 (по количеству ядер), обычно об этом пишут в инструкциях по сборке.
Там ещё много всякого есть, так то ))

Какая-то незаконченная статья, про тесты слишком мало инфы, а про упомянутую "доводку" вообще ничего нет
Но тема очень интересная, информации действительно по ней мало

Поменял docker rm -f на docker stop. Теперь даже rollback поддерживается. Если после деплоя и ручной проверки выяснилось, что новый контейнер работает хуже старого, можно вернуть старый простым docker start и заменой конфига. Что-нибудь типа такого:

rollback() {
    local image_name=${1?"Usage: ${FUNCNAME[0]} image_name"}

    if get-active-slot $image_name
    then
        local previous_slot=GREEN
        local current_slot=BLUE
    else
        local previous_slot=BLUE
        local current_slot=GREEN
    fi
    docker start ${image_name}_${previous_slot}
    set-active-slot $image_name $previous_slot
    docker stop ${image_name}_${current_slot}
}

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

Разговоры о том, кто мёртв, а кто жив, будут до тех пор, пока наконец-то все не начнут использовать %MY_FAVORITE_TECH%.

сразу в swarm идём и получаем удовольствие

Было уже про swarm выше. Я честно не знал, что swarm ещё хоть в каком-то виде жив и был немало удивлён тем, что есть некий swarm mode и он вроде как норм. Но вообще, даже есть и так, то swarm — это поделка чисто докера, а докер уже давно мёртв не только как компания, но и как реализация контейнерной технологии. В RHEL-полушарии линуксов уже даже полностью отказались от докера, заменив его на CLI-совместимый podman без центрального демона, работающего от рута, который является очень узким местом. Есть основания полагать, что скоро этот тренд и до Debian-полушария дойдёт, и тогда все точно слезут с докера. А в podman уже нет никакого недооркестратора, только k8s, только хардкор. А этого монстра далеко не везде возможно внедрить...

прикольная идея. Вроде Visual Studio подобным образом делает для отладки в докере. Но опять же подходит далеко не всегда:

1. Не всё можно обновить таким образом, если надо бампнуть версию самого HTTP сервера, то его всё-таки придётся останавливать. А современные приложения обычно сами себе HTTP сервер (как в примере), и никакого /var/www вообще нету ))
2. Засорять сервер исходниками вне контейнеров, бэээ. Зачем тогда вообще контейнер, если можно просто HTTP сервер на bare metal поднять и то же самое делать )

https://cataas.com/cat/says/%D0%BA%D0%BE%D1%82%D0%B8%D0%BA%20%D0%B4%D0%BB%D1%8F%20%D1%83%D0%BB%D1%83%D1%87%D1%88%D0%B5%D0%BD%D0%B8%D1%8F%20%D1%81%D0%BE%D1%81%D1%82%D0%BE%D1%8F%D0%BD%D0%B8%D1%8F%20%D0%B4%D1%83%D1%85%D0%B0

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