Делюсь своим личным списком бесплатного софта с популярными аналогами, может быть что-то оттуда будет полезно для этой статьи https://github.com/Himura2la/awesome-soft/
Для автоматического запуска всего при старте системы в нужном порядке и с созданием виртуальной сети можно использовать docker-compose. И контейнеры могут являться единым способом управления ворклоадом, при чем, удобно то что они не смешиваются с системными делами, и всегда можно посмотреть чистый список запущенного. Зашёл на сервер, позвал "docker ps" и все узнал про него. Логироввние ликера можно настроить так чтобы оно использовало journald, но это не обязательно, так как всегда есть "docker logs". Мне до сих пор не понятно зачем использовать возможности хост-системы (которых может и не быть в systemd-less системах) для управления контейнерами, если контейнеры и сами отлично справляются. Если что-то на холсте работает без докера, то конечно systemd-units это единственный адекватный вариант управления жизненными циклом, но docker совершенно точно обладает достаточным функционалом чтобы его заменить.
А для десятков серверов с десятками контейнеров этот подход с локальным докером в принципе не походит, тут уже оркестратор нужен. Это же три независимых подхода: systemd (+Ansible?) -> docker/podman (+ docker-compose) -> K8s/Nomad... Каждый из них полностью спмостоятельно позволяет управлять жизненным циклом ворклоада.
Все круто, но идея управять контейнерами через systemd кажется странной. Можно ведь поставить `restart: unless-stopped`, зачем для этого systemd? Или в Podman это не сработает?
По предмету статьи всё супер, было очень полезно узнать, что такой инструмент существует. Да и вообще, знать инструменты очень важно, спасибо за статью.
У меня лишь одно замечание: зачем трогать хост, есть можно всё в контейнерах сделать? Если база всё равно локальная, то почему бы её не поднять в контейнере? Можно написать docker-compose.yml файл с двумя сервисами: базой и этой прогой на go. Они автоматически объединятся в виртуальную сеть и будут доступны друг другу по хостнэйму, совпадающем у с именем контейнера. Таким образом, генерация новой наполненной базы сведётся к выполнению `docker-compose up -d`. И не нужно будет сеть хоста в докер кидать, ибо это не очень хорошо так делать. Кстати, помимо использования сети хоста, конкретно у докера есть ещё пролом с docker.host.internal, чтобы получать доступ к локалхостовым серверам
Отсутствие лени у айтишника пораждает костыли и велосипеды. Пробовать адаптировать к своей задаче готовые решения перед тем как приступить к созданию своего -- это нормальный здоровый подход, который в том числе позволяет развиваться опенсорсу.
Полагаю, что статья заминусована теми, кто держит у себя миллиарды вкладок, боится открывать лишние окна, чтобы не потерять восстановление вкладок при запуске, считает, что это удобно и обиделся. Грустно.
Спасибо за перевод, полезно. Оказывается, всё не так уж сложно. Очень хочется аналогичную статью про apt-пакеты, а то благодаря checkinstall, нет никакого повода изучить как оно там внутри (кстати, мне кажется, имеет смысл добавить примечание переводчика про checkinstall, я вот только в процессе написания этого комента узнал что он с rpm тоже работает)
Не хватает аналогичной статьи про apt-пакеты, а то благодаря checkinstall, нет никакого повода изучить как оно там внутри
Самая большая проблема мне видится с неделями... под текущие месяцы спроецировать ss-days можно, а вот пятидневная неделя отличается от семидневной слишком сильно... Коэффициент выходных сейчас у нас 2/7=0.28, чтобы добиться примерно такого же количества халявы, нужно 4й день делать сокращённый, и нулевой выходным, наверно, тогда будет 0.3. Но продуктивность в 4й день будет не очень... Если один выходной оставлять, тогда надо делать 5-часовой рабочий день
Спасибо за утилиту, главная проблема линуксовой экосистемы в том что очень много всего где-то запрятано и крайне сложно узнать, что так вообще можно ))
Хорошо, что в Arch всё так просто, а то я его совсем не рассматривал.
Так это и есть pulseaudio-module-jack, который я предлагаю использовать при наличии. Спасибо за готовую команду )
Эта рекомендация актуальна для сборки проектов, время сборки которых изменяется в минутах или часах (а не в миллисекнудах, как в статье).
Собственно, в реальной жизни обычно так и приходится запускать 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 года
Делюсь своим личным списком бесплатного софта с популярными аналогами, может быть что-то оттуда будет полезно для этой статьи https://github.com/Himura2la/awesome-soft/
Для автоматического запуска всего при старте системы в нужном порядке и с созданием виртуальной сети можно использовать docker-compose. И контейнеры могут являться единым способом управления ворклоадом, при чем, удобно то что они не смешиваются с системными делами, и всегда можно посмотреть чистый список запущенного. Зашёл на сервер, позвал "docker ps" и все узнал про него. Логироввние ликера можно настроить так чтобы оно использовало journald, но это не обязательно, так как всегда есть "docker logs". Мне до сих пор не понятно зачем использовать возможности хост-системы (которых может и не быть в systemd-less системах) для управления контейнерами, если контейнеры и сами отлично справляются. Если что-то на холсте работает без докера, то конечно systemd-units это единственный адекватный вариант управления жизненными циклом, но docker совершенно точно обладает достаточным функционалом чтобы его заменить.
А для десятков серверов с десятками контейнеров этот подход с локальным докером в принципе не походит, тут уже оркестратор нужен. Это же три независимых подхода: systemd (+Ansible?) -> docker/podman (+ docker-compose) -> K8s/Nomad... Каждый из них полностью спмостоятельно позволяет управлять жизненным циклом ворклоада.
Все круто, но идея управять контейнерами через systemd кажется странной. Можно ведь поставить `restart: unless-stopped`, зачем для этого systemd? Или в Podman это не сработает?
Ну, то что так никто не делает -- это, конечно, совсем не правда (https://github.com/kubernetes/kubeadm/blob/main/docs/ha-considerations.md#keepalived-and-haproxy), а против разлома пополам у keepalived вроде как настраивается приоритет каждой ноды, но за pacemaker спасибо, изучим чо это такое )
Интересны подробности, я совсем недавно узнал про метод с keepalived и он кажется очень хорошим, было бы интересно узнать почему это не так
По предмету статьи всё супер, было очень полезно узнать, что такой инструмент существует. Да и вообще, знать инструменты очень важно, спасибо за статью.
У меня лишь одно замечание: зачем трогать хост, есть можно всё в контейнерах сделать? Если база всё равно локальная, то почему бы её не поднять в контейнере? Можно написать docker-compose.yml файл с двумя сервисами: базой и этой прогой на go. Они автоматически объединятся в виртуальную сеть и будут доступны друг другу по хостнэйму, совпадающем у с именем контейнера. Таким образом, генерация новой наполненной базы сведётся к выполнению `docker-compose up -d`. И не нужно будет сеть хоста в докер кидать, ибо это не очень хорошо так делать. Кстати, помимо использования сети хоста, конкретно у докера есть ещё пролом с docker.host.internal, чтобы получать доступ к локалхостовым серверам
Отсутствие лени у айтишника пораждает костыли и велосипеды. Пробовать адаптировать к своей задаче готовые решения перед тем как приступить к созданию своего -- это нормальный здоровый подход, который в том числе позволяет развиваться опенсорсу.
Полагаю, что статья заминусована теми, кто держит у себя миллиарды вкладок, боится открывать лишние окна, чтобы не потерять восстановление вкладок при запуске, считает, что это удобно и обиделся. Грустно.
Спасибо за перевод, полезно. Оказывается, всё не так уж сложно. Очень хочется аналогичную статью про apt-пакеты, а то благодаря checkinstall, нет никакого повода изучить как оно там внутри (кстати, мне кажется, имеет смысл добавить примечание переводчика про checkinstall, я вот только в процессе написания этого комента узнал что он с rpm тоже работает)
Не хватает аналогичной статьи про apt-пакеты, а то благодаря checkinstall, нет никакого повода изучить как оно там внутри
Потом ещё про snap vs flatpak
Самая большая проблема мне видится с неделями... под текущие месяцы спроецировать ss-days можно, а вот пятидневная неделя отличается от семидневной слишком сильно... Коэффициент выходных сейчас у нас 2/7=0.28, чтобы добиться примерно такого же количества халявы, нужно 4й день делать сокращённый, и нулевой выходным, наверно, тогда будет 0.3. Но продуктивность в 4й день будет не очень... Если один выходной оставлять, тогда надо делать 5-часовой рабочий день
BookStack
https://github.com/Himura2la/MiLight/blob/master/ruby/Mi-Light.txt осталось только это )
Потому что Вы невнимательно читали ¯_(ツ)_/¯
pulseaudio-module-jack, который я предлагаю использовать при наличии. Спасибо за готовую команду )Интересно, откуда взялось слово
.PHONY?Эта рекомендация актуальна для сборки проектов, время сборки которых изменяется в минутах или часах (а не в миллисекнудах, как в статье).
Собственно, в реальной жизни обычно так и приходится запускать
make -j4(по количеству ядер), обычно об этом пишут в инструкциях по сборке.Там ещё много всякого есть, так то ))
Какая-то незаконченная статья, про тесты слишком мало инфы, а про упомянутую "доводку" вообще ничего нет
Но тема очень интересная, информации действительно по ней мало
Поменял
docker rm -fнаdocker stop. Теперь даже rollback поддерживается. Если после деплоя и ручной проверки выяснилось, что новый контейнер работает хуже старого, можно вернуть старый простымdocker startи заменой конфига. Что-нибудь типа такого:Я уже добавил дисклеймер про это в конец статьи. Моё мнение, что для подобных штук надо использовать k8s, но я могу ошибаться, так как нормально пощупать k8s у меня ещё не было возможности, к сожалению. Это прям стандарт отрасли сейчас, лучше придерживаться решений такого класса, чтобы не переделывать всё каждые 2 года