Всем привет, меня зовут Олег Юрчик, я старший разработчик в Cloud.ru. Современный интернет — это не только IT-гиганты и готовые облачные сервисы. Под капотом глобальной сети скрываются базовые принципы, которые может воспроизвести любой технический специалист. В этой статье сначала вспомним, как появился Интернет и как он работает, а затем разберем, как создать его уменьшенную, но полностью управляемую копию с собственными DNS, центром сертификации и веб-сервисами.
Краткая история появления сети Интернет
История Интернета ведет отсчет с 1969 года, когда Агентство перспективных исследовательских проектов (ARPA) при Министерстве обороны США, занимавшееся высокотехнологичными военными разработками, создало сеть ARPANET. Первыми узлами этой сети стали Калифорнийский университет в Лос-Анджелесе (UCLA), Стэнфордский исследовательский институт (SRI), Калифорнийский университет в Санта-Барбаре (UCSB) и Университет Юты.
Идея устойчивой децентрализованной сети, способной сохранять связь при повреждении отдельных участков, была разработана Полом Бараном и Дональдом Дэвисом. Ее устойчивость обеспечивала технология пакетной коммутации, которая разбивала данные на блоки и позволяла им самостоятельно находить путь к цели по любым доступным каналам. Ключевым принципом было равноправие всех узлов (peer-to-peer) — в сети не было главного центра, что и делало её такой живучей. В 1983 году принятие набора протоколов TCP/IP позволило объединять разные сети в единую «сеть сетей». Позднее, благодаря изобретению Всемирной паутины (WWW), Интернет стал общедоступным глобальным явлением.
Чем отличается интернет и Интернет?
Интернет с заглавной буквы — имя собственное, уникальное название глобальной сети, наследницы проекта ARPANET, которая объединяет компьютеры по всему миру с помощью стандартных протоколов (TCP/IP).
Со строчной буквы слово интернет стало нарицательным и описывает любую крупную сеть, построенную по аналогичным принципам — например, «внутренний интернет завода» (интранет) или «интернет вещей». Таким образом, «Интернет» — это одна конкретная всемирная сеть, а «интернет» — общий термин для технологии связи.
Основы работы сети интернет
При проектировании протоколов подключения и передачи информации в сети основной фокус был на задаче устойчивости сети в целом:
Как сохранить работоспособность сети, если один или несколько узлов сети будут недоступны (возможно, вообще уничтожены без возможности быстрого восстановления)?
Как снизить затраты на передачу данных по сети в условиях ограниченного количества физических каналов связи?
Как сделать так, чтобы различные ЭВМ могли быть полноценной частью сети (универсальный язык общения, протокол)?
Как в процессе изменения сети сделать так, чтобы пакеты не терялись и доходили до адресата?
Как гарантировать, что данные будут доставлены полностью и без искажений в различных физических каналах связи?
В процессе решения этих вопросов был создан набор протоколов TCP/IP, следуя которым любой компьютер мог быть подключен к сети. При этом при передаче данных у пакета нет заранее проложенного маршрута. Каждый узел сети, через который проходит трафик, основываясь на своей актуальной таблице маршрутов, определяет следующий кратчайший доступный путь к адресату. Если какой-либо узел на первоначальном пути отключается, это обнаруживается сразу и пакеты перенаправляются по обходному маршруту (если таковой имеется), обеспечивая доставку даже в условиях изменяющейся конфигурации сети.
Подробнее о работе сети Интернет можно посмотреть видео от AlekOS.
Такая отказоустойчивость заложила в основу сети принцип равноправия: влияние узла определялось не его статусом, а количеством связей с другими узлами. Каждый участник сети получил возможность не только отправлять и получать данные, но и быть ретранслятором для чужих сообщений.
Со времен создания протоколов TCP/IP более 50 лет назад, интернет, который мы знаем сейчас... фундаментально не изменился. Понимание принципов работы технологии — ключ к созданию собственной сети. Децентрализация, отказоустойчивость и равноправие узлов, заложенные в ARPANET, мы можем воплотить на практике сегодня. Давайте посмотрим, как устроен современный интернет, а затем создадим свой собственный «суверенный» сегмент, следуя тем же фундаментальным идеям.
Посмотреть, как сеть охватывала новые территории можно на этом сайте.
Какой интернет сейчас?
Большую часть времени в сети мы проводим внутри экосистем IT-гигантов: почта Google, соцсети VK и Telegram, облачные хранилища. Эти платформы монополизируют наше внимание. В противовес этому, ресурсы, созданные и поддерживаемые небольшими командами или даже одиночками, оказываются на периферии нашего цифрового опыта. Столкновение с ними стало редкостью, что наглядно показывает, куда сместился центр тяжести всемирной сети.
Карту Интернета можно посмотреть на этом сайте.
Означает ли это, что в интернете не осталось места для личных страниц и тематических форумов? Безусловно, осталось. Однако технический порог входа серьезно возрос. Если раньше для публикации сайта было достаточно иметь выход в интернет и запущенный веб-сервер вроде Apache, то сегодня к этому добавился целый ряд обязательных этапов. Сам принцип остался прежним, но путь от идеи до работающего ресурса стал сложнее и требует больше подготовительных шагов.
Основные требования к запуску своего сервиса в интернете
Что требуется для запуска интернет-сервиса сегодня:
Постоянный канал связи: необходимо гарантированное интернет-подключение с достаточной пропускной способностью и стабильностью.
Статический IP-адрес: из-за ограниченности IPv4-адресов провайдеры выдают их как отдельную платную услугу, часто недоступную для частных лиц.
Доменное имя: это обязательный элемент — пользователи не будут запоминать цифровые адреса.
TLS-сертификат: cовременные браузеры блокируют сайты без HTTPS. Сертификат подтверждает подлинность домена и шифрует соединение, защищая от перехвата данных.
К счастью, появились сервисы, которые берут эти задачи на себя:
Хостинг-провайдеры: предоставляют готовую инфраструктуру: серверы, каналы связи и статические IP-адреса.
Доменные регистраторы: позволяют закрепить за собой доменное имя на нужный срок.
Центры сертификации: выпускают TLS-сертификаты. Let's Encrypt предлагает полностью бесплатное решение с автоматическим обновлением каждые 90 дней.
Но что будет, если, например, DNS станет недоступен? Или центр авторизации отзовет сертификаты? В этой ситуации придется срочно искать альтернативы, скорее всего будет явный даунтайм всего сервиса и частичная недоступность для некоторых пользователей из-за кеширования.
Именно по этой причине, например, важные инфраструктурные системы, такие как Сбер, предлагают установку корневых сертификатов от Минцифры, чтобы в критической ситуации вам все равно были доступны эти сервисы без рисков компрометации информации.
Насколько безопасно устанавливать сертификат Минцифры РФ
Установка корневого сертификата Минцифры РФ сама по себе не означает возможность прямого «чтения» всего HTTPS-трафика, однако создает для этого серьезные предпосылки. Главная опасность заключается в том, что этот центр сертификации может выпускать поддельные, но технически доверенные браузерами сертификаты для любых интернет-ресурсов. В сочетании с контролем Роскомнадзора над операторами связи, который позволяет незаметно перенаправлять трафик пользователей через прокси-серверы, создаются условия для проведения атаки «человек посередине». Таким образом, основная угроза — не прямое дешифрование, а возможность тотального мониторинга и модификации трафика под видом легитимных сайтов. Реализация такой системы технически возможна для государственных структур, но требует развертывания сложной инфраструктуры.
Свой суверенный интернет
Можно ли стать полноправной частью сети без зависимости от провайдеров, хостингов, DNS и центров сертификации? Или наоборот, построить свой изолированный аналог всемирной паутины? Конечно можно (но частично), и сейчас я расскажу, как это сделать.
К сожалению, отказаться от интернет-провайдера вам не удастся. Точнее, теоретически это возможно, но для этого вам надо самим стать провайдером, а это крайне сложная задача.
Вот «простой» гайд, как стать интернет-провайдером.
Также дополнительные сложности может создать попытка получить статический IP-адрес. Лично мне очень везет по жизни и каждый провайдер готов предоставить мне статический IPv4-адрес за 100-200 рублей в месяц, но у моих знакомых и коллег часто были проблемы с получением такой услуги. Самый простой вариант — арендовать адрес у облачного провайдера или хостинга, где он будет стоить примерно таких же денег. Например, в Cloud.ru есть возможность получить бесплатную виртуальную машину и арендовать для нее публичный IP-адрес за 149 рублей в месяц.
Но вот самому зарегистрировать себе домен и выпускать сертификаты под него — вполне возможно. Для начала давайте попробуем установить DNS.
На сервере желательно установить Ubuntu Server — так вы можете быть уверены, что все команды и конфигурации из статьи будут работать. Также все сервисы для простоты будем поднимать через Docker, как его установить — можно прочесть здесь.
Заранее подготовим файл .env с переменными окружения, в которых укажем:
# Домен сервера
DOMAIN=example.com
# IP адрес сервера
PUBLIC_IP=123.45.67.89
# Имя центра авторизации
CA_NAME="My CA"
# Пароль центра авторизации
CA_PASSWORD=P@ssw0rd
# Email администратора
ADMIN_EMAIL=admin@example.comУстановка DNS
DNS (Domain Name System) — это «адресная книга» интернета. Когда вы вводите название сайта (например, google.com) в браузере, DNS преобразует это понятное человеку имя в числовой IP-адрес (например, 142.250.185.78), который компьютеры используют для поиска друг друга в сети. Без этой системы нам пришлось бы запоминать длинные последовательности цифр для посещения любых сайтов.
Перед развертыванием собственного DNS-сервера в Ubuntu необходимо освободить порт 53, занятый встроенной службой systemd-resolved. Эта служба обеспечивает кеширование DNS-запросов для всей системы, поэтому ее отключение без готовой замены приведет к потере доступа в интернет.
Внимание: Следующие ниже команды, особенно касающиеся отключения systemd-resolved, выполняются только на тестовом сервере или в виртуальной машине. Их выполнение на рабочей машине может привести к потере доступа в интернет.
# Останавливаем и отключаем встроенный DNS-резолвер
systemctl disable --now systemd-resolved
# Заменяем конфигурацию DNS на локальный сервер
rm /etc/resolv.conf
tee /etc/resolv.conf > /dev/null <<EOF
nameserver 127.0.0.1
search lan
EOFТеперь можно приступить к развертыванию собственного DNS-сервера. Для начала создадим в Docker общую сеть, чтобы обеспечить взаимодействие между контейнерами независимо от способа их развертывания:
docker network create internetТакже нам пригодятся общие volumes, чтобы между контейнерами можно было обмениваться файлами:
docker volume create ca-certificates-dataСоздадим конфигурационный файл dns.yaml для развертывания DNS-сервера на основе dnsmasq. Вместо стандартного подхода с конфигурационным файлом dnsmasq.conf все настройки передаются через аргументы командной строки, что обеспечивает централизованное и прозрачное управление конфигурацией.
version: "3.8"
services:
app:
image: andyshinn/dnsmasq:2.83
hostname: dns.${DOMAIN}
networks:
- internet
ports:
- "53:53/udp"
- "53:53/tcp"
command:
- "--domain-needed"
- "--bogus-priv"
- "--expand-hosts"
- "--server=1.1.1.1"
- "--server=8.8.8.8"
- "--address=/.${DOMAIN}/${PUBLIC_IP}"
networks:
internet:
external: trueКонфигурация открывает порты 53 TCP/UDP для DNS-запросов и использует созданную ранее сеть internet. Ключевая опция address сопоставляет все поддомены указанного домена (${DOMAIN}) с IP-адресом ${PUBLIC_IP}, обеспечивая перенаправление DNS-запросов.
Запустим DNS с помощью команды:
docker compose -f dns.yaml upУстановка центра сертификации
Центр сертификации (Certificate Authority, CA) — это доверенная организация, которая выполняет роль «цифрового нотариуса» в интернете. Его основная задача — подтверждать подлинность владельцев сайтов и выпускать для них цифровые TLS-сертификаты. Когда вы видите замок рядом с адресом сайта в браузере, это означает, что центр сертификации проверил этот сайт и гарантирует, что соединение с ним зашифровано, а данные передаются именно на нужный сервер, а не злоумышленнику. Таким образом, CA формируют основу системы доверия в сети, позволяя браузерам и пользователям безопасно обмениваться информацией.
В качестве центра сертификации мы будем использовать step-ca - легковесный и простой в установке и настройки сервис для выпуска TLS-сертификатов.
Создадим файл ca.yaml с содержимым:
version: "3.8"
services:
app:
image: smallstep/step-ca:0.28.4
hostname: ca.${DOMAIN}
dns:
- dns
environment:
DOCKER_STEPCA_INIT_NAME: ${CA_NAME}
DOCKER_STEPCA_INIT_DNS_NAMES: ca.${DOMAIN}
DOCKER_STEPCA_INIT_PASSWORD: ${CA_PASSWORD}
DOCKER_STEPCA_INIT_ACME: "true"
networks:
- internet
volumes:
- ca-certificates-data:/home/step
volumes:
ca-certificates-data:
external: true
networks:
internet:
external: trueТак же запустим его с помощью команды:
docker compose -f ca.yaml upУстановка пользовательских сервисов
Теперь, когда настроены DNS и центр сертификации, можно развернуть веб-сервис с SSL-сертификатом от нашего CA. В качестве примера используем OpenSpeedTest — сервис для проверки скорости интернета. Для начала настроим обратный прокси на Traefik, создав файл gateway.yaml:
version: "3.8"
services:
app:
image: traefik:v3.5
volumes:
- /var/run/docker.sock:/var/run/docker.sock:ro
- app-certificates-data:/certificates
- ca-certificates-data:/ca:ro
networks:
- internet
ports:
- 80:80
- 443:443
entrypoint:
- "/bin/sh"
- "-c"
- |
cp /ca/certs/root_ca.crt /usr/local/share/ca-certificates/ca-root.crt &&
chmod 644 /usr/local/share/ca-certificates/ca-root.crt &&
update-ca-certificates &&
exec traefik "$@"
command:
- "--log.level=INFO"
- "--providers.docker=true"
- "--providers.docker.network=internet"
- "--providers.docker.endpoint=unix:///var/run/docker.sock"
- "--providers.docker.exposedbydefault=false"
- "--entrypoints.web.address=:80"
- "--entrypoints.web.http.redirections.entrypoint.to=websecure"
- "--entrypoints.web.http.redirections.entrypoint.scheme=https"
- "--entrypoints.web.http.redirections.entrypoint.permanent=true"
"--entrypoints.websecure.address=:443"
- "--certificatesresolvers.ca.acme.httpchallenge=true"
- "--certificatesresolvers.ca.acme.httpchallenge.entrypoint=web"
- "--certificatesresolvers.ca.acme.email=${ADMIN_EMAIL}"
- "--certificatesresolvers.ca.acme.storage=/certificates/ca-acme.json"
- "--certificatesresolvers.ca.acme.caserver=https://ca.${DOMAIN}:9000/acme/acme/directory"
- "--serversTransport.rootCAs=/ca/certs/root_ca.crt"
volumes:
ca-certificates-data:
external: true
networks:
internet:
external: trueКлючевые элементы конфигурации:
Volumes: Монтирование директории центра сертификации для доступа к корневому сертификату
Entrypoint: Установка корневого сертификата в систему перед запуском Traefik
Docker Provider: Настройка автоматического обнаружения сервисов в сети
internetHTTP→HTTPS: Автоматическое перенаправление с порта 80 на 443
Certificate Resolver: Интеграция с нашим центром сертификации через ACME-протокол для автоматического выпуска TLS-сертификатов
Запускаем сервис привычной командой
docker compose -f gateway.yaml upДобавим конфигурацию сервиса OpenSpeedTest в файле speed.yaml
version: "3.8"
services:
app:
image: openspeedtest/latest:v0.0.1
networks:
- internet
labels:
- "traefik.enable=true"
- "traefik.docker.network=internet"
- "traefik.http.services.openspeedtest-app.loadbalancer.server.port=3000"
- "traefik.http.routers.openspeedtest-app.rule=Host(`speed.${DOMAIN}`)"
- "traefik.http.routers.openspeedtest-app.entrypoints=websecure"
- "traefik.http.routers.openspeedtest-app.service=openspeedtest-app"
- "traefik.http.routers.openspeedtest-app.tls.certresolver=ca"
networks:
internet:
external: trueЗапустим:
docker compose -f speed.yaml upНастройка клиента
Отлично, сторона сервера настроена. Теперь нужно сделать так, чтобы клиент (компьютер или мобильный телефон) могли использовать ваш DNS и поддерживали сертификаты, выпущенные вашим CA.
Чтобы использовать собственный DNS-сервер на компьютере, необходимо изменить настройки сетевого подключения.
В Windows это делается через «Параметры сети» → «Настройка параметров адаптера», где в свойствах IPv4 нужно указать предпочитаемый и альтернативный DNS-адреса.
В Linux/MacOS редактируется файл
/etc/resolv.conf, где указывается директиваnameserverс IP-адресом вашего DNS. Для надежности рекомендуется прописать основной и резервный DNS-серверы (например, 1.1.1.1 и 8.8.8.8), чтобы сохранить доступ к интернету при сбое вашего сервера.
Теперь, переходя по домену speed.${DOMAIN}, вы фактически соединяетесь с приложением OpenSpeedTest, но получаете предупреждение сообщение о том, что сертификат невалиден и невозможно попасть на сайт.
Так и должно быть. Браузер блокирует запрос, так как не распознаёт сертификат. Для того, чтобы браузер стал доверять сайту, надо добавить корневой сертификат центра сертификации в систему. Находится он в volume центра сертификации по пути /home/step/certs/root_ca.crt
Выгрузите его из контейнера:
docker cp ca-app-1:/home/step/certs/root_ca.crt ~/root_ca.crtТеперь загрузите его на свой компьютер и установите.
В Windows и MacOS для установки сертификата нужно открыть файл crt и следовать инструкциям программы.
В Linux надо от имени суперпользователя (или через sudo) выполнить следующие команды:
Для Debian
sudo cp root_ca.crt /usr/local/share/ca-certificates/
sudo update-ca-certificatesДля RHEL/CentOS:
sudo cp root_ca.crt /etc/pki/ca-trust/source/anchors/
sudo update-ca-trust extractИтог
Поздравляю! Вы только что создали «островок» в сети, который полностью подконтролен вам. Ваши внутренние сервисы не зависят от блокировок публичных DNS, отзывов сертификатов глобальными CA или политик IT-гигантов. Этот небольшой эксперимент наглядно показывает, как работает интернет «под капотом», возможно даже вы используете это в работе или личных проектах. Весь указанный выше код можно также скачать из репозитория.
Что у нас получилось:
Собственный DNS-сервер, который мы контролируем.
Собственный Центр Сертификации, выпускающий доверенные для нас TLS-сертификаты.
Обратный прокси-сервер (Traefik), который автоматически управляет сертификатами и маршрутизацией.
Рабочий веб-сервис (OpenSpeedTest), доступный по HTTPS с нашим сертификатом.
Эта статья — лишь один из подходов. Наверняка у кого-то из читателей уже работает кластер на Raspberry Pi с собственным DNS и CA. Если вы из таких — поделитесь в комментариях, с какими сложностями столкнулись и какой стек технологий используете.
Комментарии (55)
Vilos
03.12.2025 08:16Как увидел Cloud.ru так глаз задергался! Вы вначале сделайте чтобы ваша свистопуколка работала и не падала от каждого чиха, а потом уж людей учите.
Ryder95 Автор
03.12.2025 08:16Стараемся улучшать качество наших сервисов! Тут я скорее делюсь своим личным опытом, а не корпоративным - эти эксперименты мало имеют отношения к развёрнутому облачному сервису, но в любом случае было бы здорово, если бы вы рассказали, что мы можем улучшить, быть может я смогу помочь в улучшении определённого сервиса
JBFW
03.12.2025 08:16установку корневых сертификатов от Минцифры, чтобы в критической ситуации вам все равно были доступны эти сервисы без рисков компрометации информации
В критической ситуации можно пользоваться и самоподписанными сертификатами, и неподтвержденными - на то она и критическая.
Тут ключевой вопрос - доверие к центру сертификации.
То есть, если сервер blabla.ru защищен валидным сертификатом - то мы как бы доверяем тем, кто выпустил и подписал для него сертификат.А доверяем мы ему или нет - зависит от того, установили ли мы в систему корневые сертификаты этого удостоверяющего центра.
Но тут есть риск злоупотребления: если кто-то хочет нас обмануть и подсунуть вместо blabla.ru другой сайт, с подделанным DNS-именем и подделанным сертификатом, который тем не менее подписан доверенным удостоверяющим центром - то мы об этом не узнаем просто так. Мы же доверяем этому УЦ?
- Верьте мне! - как бы говорит он.А что, если УЦ и мошенники в сговоре? Ну например, они считают, что нам не нужно показывать настоящий blabla.ru, а нужен другой, хороший, правильный blabla.ru, одобренный?
И вот так мы приходим к вопросу репутации, и как это, аффилированности ...
Ryder95 Автор
03.12.2025 08:16Полностью согласен! Под критической ситуацией имелось ввиду, например, отзыв сертификатов от зарубежных УЦ (это же и есть официальная причина, почему надо ставить сертификаты Минцифры)
JBFW
03.12.2025 08:16В реальности отзыв сертификатов для веба практически нигде не работает.
Новые не выдадут, если захотят.это же и есть официальная причина, почему надо ставить сертификаты Минцифры
После чего (по причине зависимости ВСЕХ российских провайдеров) google.com может стать удивительно похожим на yandex.ru, причем с валидным сертификатом, подписанным Минцифры ))
samponet
03.12.2025 08:16Знаете, это все познавательно и интересно, но у меня, как не очень давно погрузившегося в Линукс платформу, есть некоторые вопросы: вот в yaml в одно месте andyshinn/dnsmasq:2.83, а в другом traefik:v3.5- как понять как правильно? Почему используется в качестве volume var/run/docker.sock:/var/run/docker.sock?
Где то используется environments, где то labels, где то command. Rtfm? В целом конструкт понятен, но вот почему в одном случае так, а в другом по другому - не понятно. Возможно, я про основы спрашиваю, но хотелось бы вектор обучения узнать.
Ryder95 Автор
03.12.2025 08:16По тем местам, где различается:
1. andyshinn/dsnmasq:2.83 и traefik:v3.5 - это разные образы (читайте - разные приложения). Разные они потому, что каждый файл - это описание отдельного приложения
2. В traefik в volume прокидывается /var/run/docker.sock, чтобы приложение traefik могло настраивать доступы через сеть (как nginx, apache и т.д.) к другим приложениям
3. environments, labels и command - это разные опции. environments - переменные окружения, labels - метки контейнера (именно их использует traefik при настройки и именно поэтому ему нужен /var/run/docker.sock), command - это команда, которая запускается в контейнере
Думаю, здесь можно даже попробовать закинуть статью в какую-нибудь LLM и прямо ваш вопрос ей задать, чтобы получить быстрый ответ, ну а вообще все эти конфиги - это основа Docker и Docker Compose, копайте в эту сторону
Volverton
03.12.2025 08:16Как сложно жить стало. Без докера никуда. Раньше две строчки в текстовом конфиге поправишь и всё работает, а теперь надо пор тянку табулированную наваять и образ собрать...
DMaslo
03.12.2025 08:16Хмм... Мне намного проще с докером чем настраивать сервера под несколько задач....
---
Я вот представил одну вещь и меня ужас охватил. Администрирование 40 хостов с разными конфигурациями и под разные нужды, и все это дело ручками... Да ну... 4 сервера - докер сварм, 40 контейнеров, под этим всем. И я вообще не парюсь... За два года был один инцидент. 2 недели в отпуску был. Место закончилось на одном хосту на менеджере, пол дня восстанавливал кластер, можно сказать с нуля. Да, технология сложная по началу, но лучше так чем bare-metal в чистом виде.
JBFW
03.12.2025 08:16Однако вот тут автора поддержим: докер позволяет поправить две строчки в одном конфиге - и не поломать при этом 122 в конфигах основной системы.
Особенно если приходится работать директором зоопарка: тут Убунта, там Альт, здесь, прости господи, Астра - и у всех всё по-разному настраивается.
А так - накатил один образ и не заморачиваешься более.
inkelyad
03.12.2025 08:16А так - накатил один образ и не заморачиваешься более.
А потом в каком-нибудь openssl или libregex находится дырка и ты, вместо того, чтобы обновить один пакет и успокоится (потому что все с ним слинковано и автоматически начинает использовать новую версию) начинаешь чесать затылок, как это весь заопарк работающих образов обновить.
JBFW
03.12.2025 08:16если приспичило:
docker exec -ti containername apt update
docker exec -ti containername apt upgradeПовторить N раз. Всё.
Sap_ru
03.12.2025 08:16И размер контейнеров улетит в космос. И это если ещё ничего не поломается, так как там под капотом часто сборище костылей, на которое ни в коем случае нельзя накатывать стандартные версии.
JBFW
03.12.2025 08:16Не улетит. Хотя смотря что считать космосом.
Я для себя так и делаю: самостоятельная сборка нового контейнера на базе дебиана, именно для того чтобы потом получить тиражируемый образ.
docker commit containername newimagename
docker save newimagename | gzip > newimagename.gzЭто не по фен-шую, но работает, вполне приемлемо.
Поддерживать намного проще, чем обновлять хост-систему, а потом внезапно столкнуться с тем, что очередная очень нужная программа не ставится из-за сломанных зависимостей, и нужно переустанавливать всё, на новую версию с нуля, с риском нарваться на несовместимости с рабочим софтом.Sap_ru
03.12.2025 08:16Ну, это неплохой компромисс. Я и сам так стараюсь делать. Но это люто против трендов и лучших практик, и очень мало кто делает. И контейнер получается заметно тяжелее "стандартных". Хотя если всё на одном базовом образе делать, то в сумме даже вполне экономия. Но когда вы это обновлять начнёте...
Либо всё сразу пересобирать на обновлённый образ, а ровно тот же гемор и риски, что что-то не заработает (и вы об этом даже не сразу узнаете). И это ни разу не проще чем если всё на одной реальной системе было.
Либо обновлять по одному контейнеру, раздельно, что приводит к взрывному и непредсказуемому росту занимаемого объёма и потребления памяти. Получить 10x к объёму на диске и потреблению памяти после первого такого обновления можно совершенно элементарно.
inkelyad
03.12.2025 08:16если приспичило:
Работает только при условии, что внутри контейнеров нечто дебианобразное. Что совсем не гарантируется.
JBFW
03.12.2025 08:16Если вы сами под себя собрали - в чем проблема?
inkelyad
03.12.2025 08:16В том, что когда в инструкции по установке предлагают ставить приложение контенером - это далеко не всегда означает 'собрать приложение в контенер'. Скорее, наоборот, предлагается тащить чей-то образ.
Если же организация сама все эти образы собирает для раскатывания по своей инфраструктуре и в случае патчей все пересобирает - то тут у меня возражений нет. Хотя и в данном случае внутри образов может быть 'тут Убунта, там Альт, здесь, прости господи, Астра + еще полдюжины базовых образов' (ну потому что каждый постовщик приложения свою базовый образ любит) - и со всем этим придется отдельно разбираться.
Ryder95 Автор
03.12.2025 08:16Часто при установке приложения на бареметалл предлагается запустить скрипт из Интернета, чтобы стянуть заранее собранный бинарник. Всё простое - это всегда менее безопасное и стабильное, вопрос выбора каждого.
Как docker образы можно собрать с нуля, так и бинарники можно скомпилить самостоятельно и поставить, и наоборот, и то и другое можно взять готовое и установитьDMaslo
03.12.2025 08:16Хмм… вот смотрите (как бы всем адресовано кто отвечал под моим клиентом). У меня Docker Swarm, оверлей-сети, один админ — а не несколько человек. Да, есть чужие образы — около 20 (Grafana, Prometheus и всё вокруг них). Обновления хостов и доставка образов идут через Ansible-плейбуки. Собственные веб-сервисы общаются только через API. Наружный и внутренний выходы разделены через Traefik. Доступы — через самоподписанные сертификаты. NFS между хостами тоже на сертификатах. Оверлей-сети чётко ограничивают, кто и с кем может общаться.
Я прекрасно понимаю, что Docker — не панацея. Но в сравнении с bare-metal это в моём случае реально проще и надёжнее. На чистом железе пришлось бы вручную обслуживать десятки конфигураций, ловить несовместимости, обновлять зависимости, контролировать окружения — и всё это без изоляции. У меня же весь стек предсказуемый: единые образы, единые сценарии развертывания, автоматизация, минимизация ручного вмешательства. Для моей архитектуры это полностью оправдано. Которую сам с нуля поднял это лучше чем...
Для моих задач Swarm — более чем достаточно, без лишней сложности и без ненужных уровней абстракции.
Отдельно по сертификатам: хочу поставить свой CA под всю инфраструктуру, но раньше с этим не работал, поэтому и решил почитать, что советуют люди, которые в теме.
inkelyad
03.12.2025 08:16Отдельно по сертификатам: хочу поставить свой CA под всю инфраструктуру, но раньше с этим не работал, поэтому и решил почитать, что советуют люди, которые в теме.
Тут такое дело - сертификат своего CA все равно надо как-то раскидывать. Да еще, как сейчас утвреждают, сертификаты должны быть нужен короткоживущими, т.е. раскидывать надо часто. Т.е. есть автоматизация.
А если есть автоматизация - то почему бы пачку self-signed не раскидывать "да, вот конкретно этом сертификатам мы доверяем".
Польза именно от CA тут становится не очень очевидна.DMaslo
03.12.2025 08:16Хмм.. мысленный процес запущен... systemd + ansible. Но пока непонятно как сервисами быть. Volume == bind. Дёшево и сердито))) теперь осталось только на этом компоуз файле это прописать. Хмм... Для домашних этот способ не подойдёт. Там NixOs и апдейты через colmena, там что-то другое должно быть... Спасибо.
litalen
03.12.2025 08:16Часто при установке приложения на бареметалл предлагается запустить скрипт из Интернета, чтобы стянуть заранее собранный бинарник.
"А если все прыгнут - вы тоже прыгнете?". Зачем повторять плохое, да еще и основывать на нем свое оправдание? За такое очень больно бьют по рукам, потому что в бинарных дистрибутивах линукса (подавляющее большинство) есть ровно один один способ установки ПО - пакеты!
Ryder95 Автор
03.12.2025 08:16Так а в чём разница с тем, чтобы запускать контейнер на основе образа? В том, что вы не знаете, на основе какого образа он собран? Соберите сами, зачем повторять плохое, да ещё и основывать на нём своё оправдание? Нужна безопасность - контролируйте весь процесс от и до. Заметьте, я не говорю, что вы обязаны пользоваться докер контейнерами, но вот что я не понимаю, почему мне говорят, что я обязан не использовать докер образы?
lordleto
03.12.2025 08:16Чаще обратная задача решается: в одном пакете обновилось и всё остальное сломалось.
При правильной поставленном процессе cicd обновить все образы занимает от 1 часа до рабочего дня, причем большее время просто ждешь пока оно обновится.
Vilos
03.12.2025 08:16Многократно поддерживаю! Люди с ума посходили с этими докерами....пихают без применения мозгов куда надо и куда не надо.
kenomimi
03.12.2025 08:16Удобно же.
Развертывание в один клик. Все в конфиге кубера (для больших масштабов), или просто в гитлабе как docker-compose (для малышей и домашних конфигов), заезжает через раннеры.
Безопасность. Дырявое/зараженое приложение должно вылезти сначала за пределы докера, потом за пределы виртуалки... Почти невозможно при должной настройке. Плюс контейнерам можно легко обрезать доступ в интернет, что еще повысит защищенность решения. Плюс свои репы контейнеров (снова гитлаб, либо нексус) с ручной синхронизацией - даже если что-то глобально поломалось, было взломано или пропал доступ - у вас останется рабочая версия. Конейнер можно обрезать в минимум, и при его взломе там делать будет нечего - не будет ни прав рута, ни даже базовых утилит linux и оболочки.
Не нужно бекапить сервера приложений. Упал - поднимается пуском нужного пайплайна, так как все конфиги в гитлабе. Очень важная тема, так как поднять классический сервер даже при наличии бекапа не всегда реально без приключений.
Изоляция. Порты видны только те, которые мы указали. Изменения в одном контейнере не влияют на остальные... Как вспомню настройку домашнего сервера на 5-7 приложений (зоопарк - нода, питон, пхп, жава) без контейнеров - волосы шевелятся. Сейчас приложений около 50, на трех нодах - вообще никакого головняка.
Кейсы, где контейнеры неприменимы, есть, но это редкость, и чаще всего глупость - например продовую БД точно не надо совать в контейнер.
VnNort
03.12.2025 08:16dnsmasq по умолчанию слушает на всех интерфейсах. С проброшенным портом 53 - любой снаружи может использовать этот сервер как открытый рекурсивный Dns и он будет отвечать на запросы и слать ответы куда скажут злоумышленники.
1.1.1.1 и 8.8.8.8 это Cloudflare и Google.
На этих ИП личный DNS всё равно зависит от внешних публичных резолверов.Пароли хранятся в чистом виде и легко доступны, если взломают смогут выпускать любые сертификаты.
Клиент тоже может подделать сертификат
Сроки действий сертификатов
docker compose -f ... up без -dи без restart:после перезагрузки сервисы могут не подняться
Правка /etc/resolv.conf на клиентах может конфликтовать с NetworkManager/systemd-resolved и периодически отъезжать.
Также стоит посмотреть на файрвол на своём зосте, порты же открыты остаются
Nooki
03.12.2025 08:16почему не развернуть адгвард днс ? тоже самое и блок рекламы
к тому же в Украине обход блокировки запрещенных сайтов
NutsUnderline
03.12.2025 08:16а теперь пытаемся открыть этот самый "суверенный" через провайдера с белым списком... или cloud.ru туда внесен?
Ryder95 Автор
03.12.2025 08:16Если говорить про белый список, то практически со 100% вероятностью Cloud.ru там будет
А если говорить про "суверенность" и независимость, то расписанная мной схема возможна только в том случае, если вы отказываетесь от провайдера и сами им становитесь. Хоть я и привёл ссылку на гайд, как стать настоящим провайдером в РФ, думаю, есть ещё один путь - это сделать свою локальную сеть с соседями и это тоже можно назвать "суверенным" решением, в нём вы сами и провайдер, и УЦ, и DNS
vikarti
03.12.2025 08:16Будет сайт cloud.ru или будут все размещенное у них?
Если второе - злобный_дроновод (списки ж у нас от дронов официально?) берет VPS'ку и ставит там VPN (а следом за ним - также поступают 100500 пользователей кому хочется Youtube'а но размещают не VPN (который нельзя) а Технические Средства Предотвращения Угроз Цензуры)
Ryder95 Автор
03.12.2025 08:16Так спрашиваете у меня, как будто я лично рецензирую этот "белый список") Эх, если бы у меня была такая власть...
Насчёт того, что Cloud.ru будет в этом белом списке я уверен потому, что вряд ли можно не внести хостера, у которого крутится ГигаЧат, Сбербанк и которым пользуются другие крупные российские компании. Но опять же, ещё нет уверенности, что этот "белый список" будет, делим шкуру неубитого медведя.
Свою же сеть можно строить где угодно, не обязательно на мощностях Cloud.ru, но так как я очень не хотел описывать ещё и построение хоумлабы и статья выпущена в корпоративном блоге, то предложение, конечно, воспользоваться услугами облачного провайдера
litalen
03.12.2025 08:16привёл ссылку на гайд, как стать настоящим провайдером в РФ
А вы сами свою ссылку читали прежде чем ее приводить? Там ни слова о специфике РФ, зато:
немало непереведенных терминов и местами машинный перевод;
скрины с сайтами исключительно на английском;
этим скринам судя по верстке, ценам и скоростям ("Pro - 3Mbps $24.95")лет 15 как минимум;
судя по упоминанию DSL специфика явно не РФ.
Вообще не про РФ, а веб-архив подсказывает что этот полумашинный перевод - из 2014 года (оригинальная статья на английском как минимум из 2011го).
Ryder95 Автор
03.12.2025 08:16Читал, и, если честно, не ожидал, что кто-то всерьёз будет воспринимать это как гайд, даже в статье в кавычки поместил. Ну если действительно интересно, то это уже вопрос отдельной статьи, я этим не занимался и просто хотел показать, что это далеко не просто (даже в далёком 2011 году и зарубежом)
litalen
03.12.2025 08:16Заголовок - кликбейт, хоть бы сделали вид что знаете что прежде всего - маршрутизация. Или хотя бы Reticulum рассмотрели какой-нибудь.
Ryder95 Автор
03.12.2025 08:16Извините, не собираюсь делать вид, почему "суверенный" должен сразу означать, что мы должны с нуля пересоздавать протоколы и делать свою маршрутизацию, плюс мне казалось, что в заголовке очень явно написал, что в статье будет разобрано - о маршрутизации ни слово.
По поводу Reticulum - это очень интересно, но непонятно, как это будет работать в рамках закона КоАП РФ 13.4.
Shayth
03.12.2025 08:16О, как раз этой штукой занимался пару недель назад при настройке хоумлабы :)
Тема интересная, но везде есть свои нюансы. К примеру - CA не всегда работает так, как хотелось бы. Из личной практики - у меня есть Caddy, который выступает и как реверс-прокси, и как локальный CA. Эта штука работает, но приколы начинаются на уровне клиента - в случае использования Android устройства сайты в том же Chrome открываются нормально, HTTPS работает, но стоит начать использовать стороннее приложение - так оно начинает игнорировать пользовательские корневые сертификаты :)
Конкретно в моем случае - личный nextcloud отлично открывался через chrome, но при попытке использовать плагин remotely save в obsidian для синхронизации базы знаний через WebDAV - obsidian ругался на невозможность установить защищённое соединение, и это все связано с тем, что obsidian игнорирует пользовательские сертификаты :)
kenomimi
03.12.2025 08:16но стоит начать использовать стороннее приложение - так оно начинает игнорировать пользовательские корневые сертификаты :)
В андроиде, очень похоже, разделение на системные и пользовательские специально сделано так, чтобы согнать всех в публичные СА и фактически запретить внутренние локальные СА. С одной стороны правильно сделано, ибо ломает возможность для правительств разных стран выпускать "православные" серты местечкового разлива и проксировать траф, с другой - сильно осложняет жизнь корпоративному юзеру и домашним инсталляциям.
В том же айфоне серты можно просунуть через "офлайновый" mdm (без подписок, инфраструктуры, и прочего, тупо официальное приложение на мак), а вот в андроиде, насколько помню, без инфраструктуры mdm не работает.
inkelyad
03.12.2025 08:16с другой - сильно осложняет жизнь корпоративному юзеру и домашним инсталляциям.
Да где уж осложняет-то? Говоришь поставить - ставит. Вполне оффлайново, если хочется. Через штатный системыный диалог.
При загрузке, правда, говорит, что такой есть. А то что в описанном примере WebDAV не понял - то это то ли разработчики клиента забыли в конфигурации еще и клиентское хранилище сертификатов подключить, то ли просто традиция в WebDAV такая устоялась - конфигурировать "этому ключику/серверу мы верим" отдельно. Потому что в детсктопных клиентах я видел то же самое. Руками добавлять/разрешать/позволять запомнить приходилось. Единсвенный, что смотрел на системные - это, кажется, только тот, что встроенный в винду и который меделенно выпиливают (или уже выпилили, не помню).
kenomimi
03.12.2025 08:16Поставить в системные нельзя без рута. Поставить в пользовательские можно, но бесполезно, так как для работы пользовательских сертов надо специально делать поддержку этого списка в приложении. Чего никто не делает, конечно же, за ооочень редким исключением, а большинство разработчиков и не знает про разделение, пока не столкнется... Это и есть подвох, в самом дизайне системы.
inkelyad
03.12.2025 08:16большинство разработчиков и не знает про разделение, пока не столкнется...
Ну так если приложение рассчитано на корпоративов и прочий self хостинг - там знают или быстро узнают. А остальным приложениям, где нельзя настроить, на какой сервер обращаться - вроде, и не нужно.
ki11j0y
Почти, держать уц на сервере так себе решение, лучшим решением будет держать бд уц у себя, выписывать сертификаты или wildcard на сервис, выстроить полноценную цепочку, root > sub > fqdn.crt, использовать crl списки, сроки любые год, два, три и тд. Я пользуюсь для этого XCA и OpenVPN веду там в другом sub, а дальше просто подключаешь сертификат как обычно, маршрутизация и все работает. Для сертификатов сайта кривая prime256v1 для openvpn secp384r1.
На примере mTLS будет не сложно выпустить для сайта https://habr.com/ru/articles/904038/
Ryder95 Автор
А почему не стоит держать УЦ у себя на сервере?
inkelyad
Потому что украденный приватный ключ от того CA, что поставлен в доверенные, позволяет сделать MitM практически для всего интернета. И общаться с таким, неограниченным ничем, по хорошему, надо где-то так, как вот тут делают. Если разные constraints на них поставлены - можно попроще.
Ryder95 Автор
Смысл был в том, чтобы другие люди тоже могли им пользоваться (ведь какой может быть суверенный Интернет без пользователей), как, например, мы все пользуемся Lets Encrypt. Конечно, в статье CA не торчит в интернет (так как это туториал и мне показалось это совсем лишним), но сразу может быть CA, для того чтобы потом это можно было открыть для всех желающих. По поводу constraints - согласен, это упущение, можно улучшить
inkelyad
Ни тут ни там, кажется, не упомянуто использование address/name constraints в CA сертификатах. Их не все либы и программы учитывают, но добавлять сильно стоит. Уменьшает риск того, что в случае кражи корня злодеи смогут сделают рабочие сертификаты для MitM не только для твоей зоны, но и для всего остального интернета.
0x00FA7A55
Смотря как держать, это всё тож самое про хранение приватных токенов. Можно было бы просто vault посоветовать, он умеет в LE, если мне не изменяет память, и там хотя бы защищает unseal.