Сделать «ревизор наоборот» — выдать всем желающим утилиту, которая будет периодически проверять доступность списка адресов. Много желающих поставят, меньше нагрузка будет на каждого индивидуально. Естественно, открыть исходники и выдать инструкции для получения детерминированного билда.
Таким образом, будет актуальный список блокирующихся адресов, который не зависит непосредственно от выгрузок реестра РКН.
Когда вы сели в т.н. «самолет», вам просто напустили в салон галюциногенных газов, и вся эта ваша «австралия» вам просто привиделась в наркотическом угаре. Вы знаете хотя бы одного человека, который летал на самолете? Правительство рисует голограммы самолетов на небе, но правду не утаить, а факт того, что ни один человек в мире не видел, чтобы самолеты «взлетали», уже говорит сам за себя.
Друзья, у которых нет бинарной совместимости с другими дистрибутивами — не такие уже и друзья. Как пример, npm-пакеты node-sass или bcrypt невозможно просто «взять и установить» на node:10-alpine — нужно через apk поставить gcc и всю обвязку, и пересобрать их. Иначе жалуется на длинные отсутствующие символы.
Лучшего всего идеологии Alpine соответствует `FROM scratch`, тем не менее, не так много желающих следовать этому пути. Одиночные образы — да, но поставить сборку на конвейер, и так, чтобы ничего не ломалось… Затраты времени на создание грамотного сборщика артефактов и всех их динамически слинкованных зависимостей в таком случае превысят стоимость сэкономленного дискового пространства.
Достоинства корректного init-процесса описываются во многих местах, включая README.md в репозитории этого образа — если ваше приложение создает субпроцессы для любых целей (сразу же в голову приходит imagemagick и его форки), вы обязаны собирать мертвых детей их детей. Делает ли это ваше приложение? Если нет, то ваш контейнер бездумно течет памятью. Если да, вы реализовали init самостоятельно, возможно, даже сделали это правильно, с обработкой всех возможных сигналов, но зачем?
cron — что плохого в cron? Предпочитаете, опять же, реализовать свой собственный cron, с преферансом и библиотекаршами, на js/python/ruby/erlang/php/etc?
ssh — мне ни разу не понадобился, и я отключил его при сборке. Соглашусь с вами в том, что ssh внутри контейнера не нужен, т.к. есть docker exec, а сам контейнер должен быть максимально эфемерным и stateless.
syslog — если у вас логи очень простые и syslog вам не нужен, это замечательно. В случае нашего проекта, у нас json-логи, мы добавляем к каждой записи кучу дополнительной информации об окружении, плюс в зависимости от окружения (dev / staging) мы можем запустить все наши сервисы в одном контейнере, чтобы упростить отладку. Неизобретение своих велосипедов, а использование стандартного клиента для syslog сильно облегчает жизнь тому, кто потом читает агрегированный JSON-лог. Можно, конечно, было бы изобрести свой сервис логгирования, и скармливать логи в него удаленно, но зачем дублировать существующую инфраструктуру docker logs?
Что касается супервизора — я видел в куче других проектов использование nodemon, supervisor, foreman и т.д. для того, чтобы переподнять проект, если он упал. В нашем проекте мы используем внешнюю оркестрацию (через docker swarm), а на этапе разработки позволяем одному крешнувшемуся процессу утянуть за собой весь контейнер (чтобы нельзя было пропустить баг). Кому-то будет удобно и полезно, если организовывать контейнер так, чтобы внутри него был один логический микросервис, с кучей других процессов, будь то ntp, или init, или syslog, которые являются «деталью реализации».
Я же не предлагаю в этот образ запихивать весь проект, для такой идеологии уже есть vagrant.
Но как они собираются сделать, если многочисленные научные исследования доказали, что Луна — это голограмма, которую проецируют на небесный свод над плоской Землей?
Скорость впечатляет, конечно. А сколько разговоров было про эти ваши «ото», «сто» и прочие относительности. А начальство сказало «надо», так сели и сразу сделали.
Для того, чтобы e2e шифрование работало между разными мессенджерами, оно должно быть описано как часть протокола. Как шифровать, какими алгоритмами, как согласовывать ключи, как их менять, как шифровать многопользовательские чаты, как обрабатывать историю для свежеприсоединившихся клиентов… Это слишком много, чтобы просто засунуть все в «как-нибудь сделать end-to-end шифрование», если стороны заинтересованы в том, чтобы результат был рабочим. Вспомните WebRTC.
Таким образом, будет актуальный список блокирующихся адресов, который не зависит непосредственно от выгрузок реестра РКН.
Достоинства корректного init-процесса описываются во многих местах, включая README.md в репозитории этого образа — если ваше приложение создает субпроцессы для любых целей (сразу же в голову приходит imagemagick и его форки), вы обязаны собирать мертвых детей их детей. Делает ли это ваше приложение? Если нет, то ваш контейнер бездумно течет памятью. Если да, вы реализовали init самостоятельно, возможно, даже сделали это правильно, с обработкой всех возможных сигналов, но зачем?
cron — что плохого в cron? Предпочитаете, опять же, реализовать свой собственный cron, с преферансом и библиотекаршами, на js/python/ruby/erlang/php/etc?
ssh — мне ни разу не понадобился, и я отключил его при сборке. Соглашусь с вами в том, что ssh внутри контейнера не нужен, т.к. есть docker exec, а сам контейнер должен быть максимально эфемерным и stateless.
syslog — если у вас логи очень простые и syslog вам не нужен, это замечательно. В случае нашего проекта, у нас json-логи, мы добавляем к каждой записи кучу дополнительной информации об окружении, плюс в зависимости от окружения (dev / staging) мы можем запустить все наши сервисы в одном контейнере, чтобы упростить отладку. Неизобретение своих велосипедов, а использование стандартного клиента для syslog сильно облегчает жизнь тому, кто потом читает агрегированный JSON-лог. Можно, конечно, было бы изобрести свой сервис логгирования, и скармливать логи в него удаленно, но зачем дублировать существующую инфраструктуру docker logs?
Что касается супервизора — я видел в куче других проектов использование nodemon, supervisor, foreman и т.д. для того, чтобы переподнять проект, если он упал. В нашем проекте мы используем внешнюю оркестрацию (через docker swarm), а на этапе разработки позволяем одному крешнувшемуся процессу утянуть за собой весь контейнер (чтобы нельзя было пропустить баг). Кому-то будет удобно и полезно, если организовывать контейнер так, чтобы внутри него был один логический микросервис, с кучей других процессов, будь то ntp, или init, или syslog, которые являются «деталью реализации».
Я же не предлагаю в этот образ запихивать весь проект, для такой идеологии уже есть vagrant.