По предмету статьи всё супер, было очень полезно узнать, что такой инструмент существует. Да и вообще, знать инструменты очень важно, спасибо за статью.
У меня лишь одно замечание: зачем трогать хост, есть можно всё в контейнерах сделать? Если база всё равно локальная, то почему бы её не поднять в контейнере? Можно написать 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 года
Было уже про swarm выше. Я честно не знал, что swarm ещё хоть в каком-то виде жив и был немало удивлён тем, что есть некий swarm mode и он вроде как норм. Но вообще, даже есть и так, то swarm — это поделка чисто докера, а докер уже давно мёртв не только как компания, но и как реализация контейнерной технологии. В RHEL-полушарии линуксов уже даже полностью отказались от докера, заменив его на CLI-совместимый podman без центрального демона, работающего от рута, который является очень узким местом. Есть основания полагать, что скоро этот тренд и до Debian-полушария дойдёт, и тогда все точно слезут с докера. А в podman уже нет никакого недооркестратора, только k8s, только хардкор. А этого монстра далеко не везде возможно внедрить...
прикольная идея. Вроде Visual Studio подобным образом делает для отладки в докере. Но опять же подходит далеко не всегда:
Не всё можно обновить таким образом, если надо бампнуть версию самого HTTP сервера, то его всё-таки придётся останавливать. А современные приложения обычно сами себе HTTP сервер (как в примере), и никакого /var/www вообще нету ))
Засорять сервер исходниками вне контейнеров, бэээ. Зачем тогда вообще контейнер, если можно просто HTTP сервер на bare metal поднять и то же самое делать )
Ну, разные области применения у инструментов. У нас, например, нет таких нагрузок и нет потребности в авторизации, так что мы даже не в курсе этих проблем. А простота установки и использования подкупает.
Интересны подробности, я совсем недавно узнал про метод с 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 года
Было уже про swarm выше. Я честно не знал, что swarm ещё хоть в каком-то виде жив и был немало удивлён тем, что есть некий swarm mode и он вроде как норм. Но вообще, даже есть и так, то swarm — это поделка чисто докера, а докер уже давно мёртв не только как компания, но и как реализация контейнерной технологии. В RHEL-полушарии линуксов уже даже полностью отказались от докера, заменив его на CLI-совместимый podman без центрального демона, работающего от рута, который является очень узким местом. Есть основания полагать, что скоро этот тренд и до Debian-полушария дойдёт, и тогда все точно слезут с докера. А в podman уже нет никакого недооркестратора, только k8s, только хардкор. А этого монстра далеко не везде возможно внедрить...
прикольная идея. Вроде Visual Studio подобным образом делает для отладки в докере. Но опять же подходит далеко не всегда:
/var/wwwвообще нету ))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
Ну, разные области применения у инструментов. У нас, например, нет таких нагрузок и нет потребности в авторизации, так что мы даже не в курсе этих проблем. А простота установки и использования подкупает.