Перевод статьи подготовлен для студентов курса «Безопасность Linux». Интересно развиваться в данном направлении? Смотрите запись трансляции мастер-класса Ивана Пискунова «Безопасность в Linux в сравнении с Windows и MacOS»

В этой статье я расскажу о шагах по настройке DNS-сервера на RHEL 7 или CentOS 7. Для демонстрации я использовал Red Hat Enterprise Linux 7.4. Наша цель — создать одну A-запись и одну PTR-запись для зоны прямого и обратного просмотра соответственно.

В данной статье хотелось бы раскрыть возможности прозрачного проксирования, которое позволяет абсолютно незаметно для клиентов перенаправлять весь либо часть трафика через внешние прокси-серверы.

Когда я начинал решать данную задачу то столкнулся с тем, что её реализация имеет одну существенную проблему — протокол HTTPS. В старые добрые времена особых проблем с прозрачным проксированием HTTP не возникало, но при проксировании HTTPS браузеры сообщают о вмешательстве в протокол и на этом счастье заканчивается.

В распространенных инструкциях к прокси-серверу Squid предлагают даже сгенерировать собственный сертификат и установить его клиентам, что полный бред как минимум нерационально и выглядит как MITM — атака. Я знаю, что Squid уже что-то подобное умеет делать, но речь в этой статье о проверенном и рабочем способе с использованием 3proxy от уважаемого 3APA3A.

Далее мы подробно рассмотрим процесс сборки 3proxy из исходников, его настройку, полное и выборочное проксирование с использованием NAT, распределение канала на несколько внешних прокси-серверов, а также использование роутера и статических маршрутов. В качестве ОС используем Debian 9 x64. Начинаем!

Салют, хабровчане! Перевод следующей статьи подготовлен специально для студентов курса «Инфраструктурная платформа на основе Kubernetes», занятия по которому стартуют уже завтра. Начнем.

Автомасштабирование в Kubernetes

Автомасштабирование позволяет автоматически увеличивать и уменьшать рабочие нагрузки в зависимости от использования ресурсов.

У автомасштабирования в Kubernetes два измерения:

• автомасштабирование кластера (Cluster Autoscaler), которое отвечает за масштабирование узлов;
• горизонтальное автомасштабирование подов (Horizontal Pod Autoscaler, HPA), которое автоматически масштабирует количество подов в развертывании или наборе реплик.

Автомасштабирование кластера можно использовать в сочетании с горизонтальным автомасштабированием подов для динамического регулирования вычислительных ресурсов и степени параллелизма системы, необходимых для соблюдения соглашений об уровне обслуживания (SLA).

Эта статья использует устаревший и не самый рациональный подход, на данный момент не могу его рекомендовать к использованию. Рекомендую к прочтению следующую статью.

В данной статье я расскажу о своём опыте "заворачивания" Laravel-приложения в Docker-контейнер да так, что бы и локально с ним могли работать frontend и backend разработчики, и запуск его на production был максимально прост. Так же CI будет автоматически запускать статические анализаторы кода, phpunit-тесты, производить сборку образов.

"А в чём, собственно, сложность?" — можешь сказать ты, и будешь отчасти прав. Дело в том, что этой теме посвящено довольно много обсуждений в русскоязычных и англоязычных комьюнити, и почти все изученные треды я бы условно разделил на следующие категории:

• "Использую докер для локальной разработки. Ставлю laradock и беды не знаю". Круто, но как обстоят дела с автоматизацией и запуском на production?
• "Собираю один контейнер (монолит) на базе fedora:latest (~230 Mb), ставлю в него все сервисы (nginx, бд, кэш, etc), запускаю всё супервизором внутри". Тоже отлично, прост в запуске, но как на счёт идеологии "один контейнер — один процесс"? Как обстоят дела с балансировкой и управлением процессами? Как же размер образа?
• "Вот вам куски конфигов, приправляем выдержками из sh-скриптов, добавим магических env-значений, пользуйтесь". Спасибо, но как же на счёт хотя бы одного живого примера, который я бы мог форкнуть и полноценно поиграться?

Для нетерпеливых — ссылка на репозиторий, склонировав который ты сможешь запустить Laravel-приложение одной командой. Так же не составит труда его запустить на том же rancher, правильно "слинковав" контейнеры, или использовать продуктовый вариант docker-compose.yml как отправную точку.

Данной статьей продолжается


Как мы уже писали в первой статье, есть весьма большое число программ резервного копирования, основанных на rsync.

Из тех, что больше всего подходят под наши условия, я буду рассматривать 3: rdiff-backup, rsnapshot и burp.

В комментариях к моей статье Docker: вредные советы было много просьб объяснить, чем так ужасен описанный в ней Dockerfile.

Краткое содержание предыдущей серии: два разработчика в жестком дедлайне составляют Dockerfile. В процессе к ним заходит Ops Игорь Иванович. Итоговый Dockerfile плох настолько, что ИИ оказывается на грани инфаркта.

Сейчас разберемся, что не так с этим Dockerfile.

Итак, прошла неделя.

Это не готовая инструкция, с большим количеством кода, а скорее описание алгоритма и результатов чего мы добились.

Итак, не так давно у нас появился новый клиент. У него было несколько нетипичных для нас требований: использовать для конфигурирования серверов ansible, контент сайта хранится в git, каждый сайт находится на своей виртуальной машине. Все это не сулило ничего хорошего, так как совсем не укладывалось в стандартную схему «Клиент всегда прав!», и мы начали разрабатывать новую схему. Но обо всем по порядку.

Исходные данные: есть клиент, у которого более 30 сайтов которые надо перенести на нашу площадку. Каждый сайт должен располагаться в отдельном контейнере (мы используем OpenVZ контейнеры). Используется только один внешний IP. Для конфигурирования серверов используется ansible. Для каждого сайта есть архив с конфигурационными файлами. Контент сайта находится в git.

И мы начали творить… Что у нас получилось, можно посмотреть под катом. Забегая вперед, скажу, разворот нового сайта сводится к нескольким командам.

Думаю, любой системный администратор, использующий Ansible для управления своим зоопарком серверов задавался вопросом о проверке корректности описания конфигурации своих серверов. Как же не бояться вносить изменения в конфигурации серверов?
В серии статей, посвященных DevOps, мы расскажем об этом.

Создание первой цепочки DevOps за пять шагов для новичков.

DevOps стал панацеей для слишком медленных, разобщенных и прочих проблемных процессов разработки. Но нужны минимальные познания в DevOps. Здесь будет рассмотрены такие понятия, как цепочка DevOps и как создать ее за пять шагов. Это не полное руководство, а только “рыба”, которую можно расширять. Начнем с истории.

Мое знакомство с DevOps

Когда-то я работал с облаками в Citi Group и разрабатывал веб-приложение IaaS, чтобы управлять облачной инфраструктурой Citi, но мне всегда было интересно, как можно оптимизировать цепочку разработки и улучшить культуру среди разработчиков. Грег Лавендер, наш техдиректор по облачной архитектуре и инфраструктуре, посоветовал мне книгу Проект «Феникс». Она прекрасно объясняет принципы DevOps, при этом читается, как роман.

Автор статьи, перевод которой мы сегодня публикуем, говорит, что она предназначена для тех разработчиков, которые хотят изучить Docker Compose и идут к тому, чтобы создать своё первое клиент-серверное приложение с использованием Docker. Предполагается, что читатель этого материала знаком с основами Docker. Если это не так — можете взглянуть на эту серию материалов, на эту публикацию, где основы Docker рассмотрены вместе с основами Kubernetes, и на эту статью для начинающих.

Когда я учился водить машину, на первом же занятии инструктор выехал на перекресток задним ходом, а потом сказал, что делать так нельзя — вообще никогда. Это правило я запомнил сразу и на всю жизнь.

Читаешь детям «Вредные советы» Григория Остера, и видишь, как легко и непринужденно до них доходит, что так делать нельзя.

О том, как правильно писать Dockerfile, написана куча статей. Но мне не попадалось инструкций, как писать неправильные Dockerfile. Восполняю этот пробел. И, может быть, в проектах, которые я получаю на поддержку, таких докерфайлов станет меньше.

При запуске кластера Kubernetes для конкретного приложения следует понимать, какие требования представляет к этому ресурсу само приложение, бизнес и разработчики. При наличии этой информации можно приступать к принятию архитектурного решения и, в частности, к выбору конкретного Ingress-контроллера, коих на сегодняшний день уже большое количество. Чтобы составить базовое представление об имеющихся вариантах без необходимости изучать множество статей/документации и т.п., мы и подготовили этот обзор, включив в него основные (production ready) Ingress-контроллеры.

Надеемся, что он поможет коллегам в выборе архитектурного решения — по крайней мере, станет отправной точкой для получения более подробной информации и практических экспериментов. Предварительно мы изучили другие подобные материалы в сети и, как ни странно, не обнаружили ни одного более-менее полного, а главное — структурированного — обзора. Итак, заполним же этот пробел!

Я создал Kube Eagle — экспортер Prometheus. Оказалось, крутая штука, которая помогает лучше разбираться в ресурсах маленьких и средних кластеров. В итоге я сэкономил не одну сотню долларов, потому что подбирал правильные типы машин и настраивал ограничения ресурсов приложений под рабочие нагрузки.

Я расскажу о преимуществах Kube Eagle, но сначала объясню, из-за чего вышел сыр-бор и для чего понадобился качественный мониторинг.

Часть 1/3 тут.

Часть 2/3 тут.

Всем привет! А вот и третья часть руководства «Kubernetes на «голом железе»! Я уделю внимание мониторингу кластера и сбору логов, также мы запустим тестовое приложение для использования предварительно настроенных компонентов кластера. Затем проведем несколько стресс-тестов и проверим стабильность этой кластерной схемы.

«Нужно активнее нести DevOps в массы», — решили мы в прошлом году, провели масштабный ребрендинг RootConf и запустили DevOpsConf, как место, где инженеры смогли обсудить множество насущных проблем и посмотреть на то, что же творится вокруг, чем живут в близких областях, как выходят из похожих, но все же отличных ситуаций. Нам удалось собрать классную программу и, что еще важнее, аудиторию профессионалов, которым боли и их решения были нужны и понятны.

Что ж, не будем останавливаться на достигнутом — продолжим продвижение подхода интеграции процессов разработки, тестирования и эксплуатации уже в мае на РИТ++.


Поскольку DevOps в нашем понимании — это про объединение всех процессов разработки, то фестиваль конференций РИТ++, в котором участвуют и серверные и клиентские разработчики, и управленцы разных уровней, люди, выстраивающие бизнес-процессы, и многие другие специалисты IT, — самое место, чтобы говорить о DevOps.

От переводчика: этот текст — перевод записи в личном блоге Михаэля Штапельберга (Michael Stapelberg) видного open source-разработчика (профиль GitHub), который внес значительный вклад в развитие Debian.

---

Этот пост было сложно написать с эмоциональной точки зрения, но я и не ограничился «коротким письмом, потому что у меня не было времени». Пожалуйста, перед прочтением этого текста учтите, что пишу я его с лучшими намерениями и не ставлю себе целью демотивировать или принизить вклад кого-то из разработчиков. Скорее, я хочу объясниться, почему мой уровень разочарования превысил все допустимые значения.

Debian был частью моей жизни на протяжении 10 лет.

Несколько недель назад, на посвященной Debian встрече, проходившей в Цюрихе, я встретился со своими старыми друзьями, которых не видел много лет. Когда я уже ехал домой на велосипеде, меня осенило, что все обсуждаемые нами темы так или иначе сводились к тому, что мы обсуждали с ними в прошлый раз. Мы дискутировали о достоинствах systemd, который вновь привлек внимание участников open source сообщества, затронули тему процессов в Debian. Кульминацией стало обсуждение демократии как таковой и соответствующие теоретические и практические ошибки. Но, на самом деле, это уже чисто швейцарская тема.

Это не обзор прошедшего митапа, я просто хочу объяснить, что побудило меня задуматься о своем текущем отношении к Debian и подходит ли он мне.

Итак, я принял решение, которое должен был принять давно: я сворачиваю свое участие в развитии Debian.

Прим. перев.: Автор статьи — Melvin Dave Vivas, возглавляющий команду разработчиков и SRE-инженеров в сингапурском банке, — делится своим опытом знакомства с поддержкой Kubernetes в платформе Docker.

Когда в октябре прошлого года на DockerCon 2017 технический директор Docker Inc Соломон Хайкс (Solomon Hykes) анонсировал родную поддержку Kubernetes, мне стало очень любопытно, как это будет работать.



Поэтому после анонса я решил проверить наличие этой поддержки в Edge-версии, о чём писал Michael Frills в блоге Docker. Но на тот момент её не оказалось. И вот, после нескольких месяцев ожиданий, она наконец-то появилась.

Свой блог мы начнём с публикаций, созданных по мотивам последних выступлений нашего технического директора distol (Дмитрия Столярова). Все они состоялись в 2016 году на различных профессиональных мероприятиях и были посвящены теме DevOps и Docker. Одно видео, со встречи Docker Moscow в офисе Badoo, мы уже публиковали на сайте. Новые будут сопровождаться статьями, передающими суть докладов. Итак…

31 мая на конференции RootConf 2016, проходившей в рамках фестиваля «Российские интернет-технологии» (РИТ++ 2016), секция «Непрерывное развертывание и деплой» открылась докладом «Лучшие практики Continuous Delivery с Docker». В нём были обобщены и систематизированы лучшие практики построения процесса Continuous Delivery (CD) с использованием Docker и других Open Source-продуктов. С этими решениями мы работаем в production, что позволяет опираться на практический опыт.



Если у вас есть возможность потратить час на видео с докладом, рекомендуем посмотреть его полностью. В ином случае — ниже представлена основная выжимка в текстовом виде.

6 июня на конференции RootConf 2017, проходившей в рамках фестиваля «Российские интернет-технологии» (РИТ++ 2017), в секции «Непрерывное развертывание и деплой» прозвучал доклад «Наш опыт с Kubernetes в небольших проектах». В нём рассказывалось об устройстве, принципах работы и основных возможностях Kubernetes, а также о нашей практике использования этой системы в небольших проектах.

По традиции мы рады представить видео с докладом (около часа, гораздо информативнее статьи) и основную выжимку в текстовом виде.

Прим. перев.: Автор оригинальной статьи — Théo Chamley, архитектор облачных решений Google. В этой публикации для блога Google Cloud он представил краткую выжимку из более детального руководства его компании, названного «Best Practices for Operating Containers». В нём специалисты Google собрали лучшие практики по эксплуатации контейнеров в контексте использования Google Kubernetes Engine и не только, затронув широкий спектр тем: от безопасности до мониторинга и журналирования. Итак, какие практики в работе с контейнерами наиболее важны по мнению Google?