OpenVPN, как много в этом слове. Мультиплатформенный, гибко настраиваемый, бесплатный VPN сервер с открытым исходным кодом, являющийся фактически стандартом "defacto" для организации доступа к внутренним корпоративным сетям. Большинство администраторов используют его с настройками по умолчанию или с типовыми конфигурациями широко описанными в разных HOW-TO. Но так ли прост OpenVPN, как он кажется на первый взгляд? В данной статье мы рассмотрим скрытые от глаз внутренние механизмы OpenVPN, которые кардинально меняют представление о его возможностях.
«Надежность и безотказность как в Google» — и не только: перевод статьи «Расчёт надёжности сервиса»
14 мин
Перевод
Главная задача коммерческих (да и некоммерческих тоже) сервисов — быть всегда доступными для пользователя. Хотя сбои случаются у всех, вопрос в том, что делает IT-команда для их минимизации. Мы перевели статью Бена Трейнора, Майка Далина, Вивек Рау и Бетси Бейер «Расчёт надёжности сервиса», в которой рассказывается, в том числе, на примере Google, почему 100% — неверный ориентир для показателя надежности, что такое «правило четырёх девяток» и как на практике математически прогнозировать допустимость крупных и мелких отключений сервиса и\или его критических компонентов — ожидаемое количество простоя, время обнаружения сбоя и время восстановления сервиса.
Тестирование PostgreSQL с HugePages в Linux
4 мин
Перевод
Ядро Linux предоставляет широкий спектр параметров конфигурации, которые могут повлиять на производительность. Главное — выбрать правильную конфигурацию для вашего приложения и рабочей нагрузки. Как и любой другой базе данных, PostgreSQL необходима оптимальная настройка ядра Linux. Неправильные настройки могут привести к снижению производительности. Важно проводить сравнительный анализ производительности базы данных после каждого сеанса настройки. В одном из своих предыдущих постов под названием "Tune Linux Kernel Parameters For PostgreSQL Optimization" я описал некоторые из наиболее полезных параметров ядра Linux и то, как они помогают повысить производительность базы данных. Теперь я поделюсь результатами сравнительного тестирования после настройки HugePages в Linux под различными нагрузками PostgreSQL. Я провел полный набор тестов под множеством различных нагрузок PostgreSQL с различным числом параллельных клиентов.
End-to-end тестирование микросервисов c Catcher
8 мин
Добрый день! Я хотел бы представить новый инструмент для end-to-end тестирования микросервисов – Catcher
Зачем тестировать?
Зачем нужно e2e тестирование? Мартин Фаулер рекомендует избегать его в пользу более простых тестов.
Nomad: проблемы и решения
9 мин
Первый сервис в Nomad я запустил в сентябре 2016 года. На данный момент пользуюсь как программист и занимаюсь поддержкой как администратор двух Nomad кластеров — один "домашний" для своих личных проектов (6 микро-виртуалок в Hetzner Cloud и ArubaCloud в 5 разных датацентрах Европы) и второй рабочий (порядка 40 приватных виртуальных и физических серверов в двух датацентрах).
За прошедшее время накопился довольно большой опыт работы с Nomad окружением, в статье опишу встреченные проблемы Nomad и как с ними можно справиться.
Ямальский кочевник делает Continous Delivery инстанса вашего ПО © National Geographic Россия
Как взять сетевую инфраструктуру под свой контроль. Глава третья. Сетевая безопасность. Часть первая
9 мин
Эта статья является третьей в цикле статей «Как взять сетевую инфраструктуру под свой контроль». Содержание всех статей цикла и ссылки можно найти здесь.
Нет смысла говорить о полном устранении security рисков. Мы в принципе не можем снизить их до нуля. Также нужно понимать, что при стремлении сделать сеть более и более безопасной наши решения становятся все более и более дорогими. Необходимо найти разумный для вашей сети компромисс между ценой, сложностью и безопасностью.
Конечно, дизайн безопасности органично встроен в общую архитектуру и используемые security решения влияют на масштабируемость, надежность, управляемость, … сетевой инфраструктуры, что также должно учитываться.
Но, напомню, что сейчас мы не говорим о создании сети. В соответствии с нашими начальными условиями у нас уже выбран дизайн, выбрано оборудование, и создана инфраструктура, и на этом этапе мы, по возможности, должны «жить» и находить решения в контексте выбранного ранее подхода.
Наша задача сейчас – выявить риски, связанные с защищенностью на уровне сети и снизить их до разумной величины.
Нет смысла говорить о полном устранении security рисков. Мы в принципе не можем снизить их до нуля. Также нужно понимать, что при стремлении сделать сеть более и более безопасной наши решения становятся все более и более дорогими. Необходимо найти разумный для вашей сети компромисс между ценой, сложностью и безопасностью.
Конечно, дизайн безопасности органично встроен в общую архитектуру и используемые security решения влияют на масштабируемость, надежность, управляемость, … сетевой инфраструктуры, что также должно учитываться.
Но, напомню, что сейчас мы не говорим о создании сети. В соответствии с нашими начальными условиями у нас уже выбран дизайн, выбрано оборудование, и создана инфраструктура, и на этом этапе мы, по возможности, должны «жить» и находить решения в контексте выбранного ранее подхода.
Наша задача сейчас – выявить риски, связанные с защищенностью на уровне сети и снизить их до разумной величины.
5 уроков, которые мы усвоили, написав более 300 000 строк инфраструктурного кода
5 мин
Перевод
Краткий мастер-класс по разработке инфраструктурного кода
В октябре этого года я выступил с докладом на конференции HashiConf 2018, где рассказал о 5 ключевых уроках, которые я и мои коллеги из Gruntwork усвоили в процессе создания и поддержки библиотеки из более чем 300 000 строк инфраструктурного кода, используемой в производственных системах сотнями компаний. В этой публикации я поделюсь видео и слайдами с выступления, а также сокращенной текстовой версией описания 5 основных уроков.
Видео и слайды
Вступление: DevOps сейчас — в «каменном веке»
Несмотря на то, что индустрия полна модных прогрессивных слов: Kubernetes, микросервисы, сервисные сетки, неизменяемая инфраструктура, большие данные, озера данных и т. д., — реальность такова, что, когда ты с головой погружен в создание инфраструктуры, ты не чувствуешь себя таким уж модным и прогрессивным.
Как взять сетевую инфраструктуру под свой контроль. Глава вторая. Чистка и документирование
8 мин
Эта статья является второй в цикле статей «Как взять сетевую инфраструктуру под свой контроль». Содержание всех статей цикла и ссылки можно найти здесь.
Наша цель на данном этапе — наведение порядка в документации и конфигурации.
На выходе этого процесса у вас должен быть необходимый комплект документов и сеть, сконфигурированная в соответствии с ними.
Сейчас мы не будем говорить об аудите безопасности – этому будет посвящена третья часть.
Сложность выполнения поставленной на этом этапе задачи, конечно, сильно варьируется от компании к компании.
Идеальная ситуация – это когда
В этом случае ваша задача довольно проста. Вы должны изучить документы и просмотреть все те изменения, которые были сделаны.
В худшем варианте у вас будет
Понятно, что ваша ситуация где-то между, но, к сожалению, на этой шкале лучше – хуже с большой вероятностью, вы будете находиться ближе к худшему концу.
Наша цель на данном этапе — наведение порядка в документации и конфигурации.
На выходе этого процесса у вас должен быть необходимый комплект документов и сеть, сконфигурированная в соответствии с ними.
Сейчас мы не будем говорить об аудите безопасности – этому будет посвящена третья часть.
Сложность выполнения поставленной на этом этапе задачи, конечно, сильно варьируется от компании к компании.
Идеальная ситуация – это когда
- ваша сеть была создана в соответствии с проектом и вы имеете полный комплект документов
- в вашей компании был внедрен процесс контроля и управления изменениями для сети
- в соответствии с этим процессом вы располагаете документами (в том числе и всеми необходимыми схемами), предоставляющими полную информацию об актуальном положении вещей
В этом случае ваша задача довольно проста. Вы должны изучить документы и просмотреть все те изменения, которые были сделаны.
В худшем варианте у вас будет
- сеть, созданная без проекта, без плана, без согласования, инженерами, не обладающими достаточным уровнем квалификации,
- с хаотичными, не задокументированными изменениями, с большим количеством «мусора» и неоптимальных решений
Понятно, что ваша ситуация где-то между, но, к сожалению, на этой шкале лучше – хуже с большой вероятностью, вы будете находиться ближе к худшему концу.
Как Иван метрики DevOps делал. Начало
4 мин
Однажды Ивана позвали на совещание, чтобы обсудить метрики DevOps.
Каждый участник подготовил к встрече перечень неких метрики, которые на его взгляд, стоило бы реализовать.
Слушая доклады Иван попытался подсчитать сколько метрик было предложено: 5,10, опять 10, и еще около десятка. Получилось 30 с чем-то.
Почему-то неожиданно пришла мысль о том, что собравшиеся люди просто погуглили и выписали те, названия которые показались им интересными. О сути метрик, судя по всему, никто не думал.
Наблюдая со стороны Иван задавал себе вопросы: зачем? Почему именно эти метрики? Что они вам дадут? Стало вдруг очевидно, что на совещании собрались люди, совершенно далекие от реального понимания природы метрик, и что всё закончится как обычно, потерей огромного количества времени и выбрасыванием наработок в мусор.
Стало грустно и обидно. Обидно за то, что время и деньги компании просто уходят в никуда, и грустно от того, что полезное дело так и не будет сделано.
Иван уже длительное время изучал метрики и давно понял, что тема это очень серьезная и сложная, и подходить к ней с бухты-барахты нельзя ни в коем случае.
В тот день совещание закончилось всем и ничем – решили реализовать всё разом (никто не хотел брать на себя ответственность отказа, т.к. не понимал зачем эти метрики нужны другому человеку).
Иван решил подготовить своё видение метрик DevOps, причём сделать так, чтобы каждая метрика была в нём обоснована, имела конкретную цель, несла пользу и была понятна.
Вот, что у него получилось…
Каждый участник подготовил к встрече перечень неких метрики, которые на его взгляд, стоило бы реализовать.
Слушая доклады Иван попытался подсчитать сколько метрик было предложено: 5,10, опять 10, и еще около десятка. Получилось 30 с чем-то.
Почему-то неожиданно пришла мысль о том, что собравшиеся люди просто погуглили и выписали те, названия которые показались им интересными. О сути метрик, судя по всему, никто не думал.
Наблюдая со стороны Иван задавал себе вопросы: зачем? Почему именно эти метрики? Что они вам дадут? Стало вдруг очевидно, что на совещании собрались люди, совершенно далекие от реального понимания природы метрик, и что всё закончится как обычно, потерей огромного количества времени и выбрасыванием наработок в мусор.
Стало грустно и обидно. Обидно за то, что время и деньги компании просто уходят в никуда, и грустно от того, что полезное дело так и не будет сделано.
Иван уже длительное время изучал метрики и давно понял, что тема это очень серьезная и сложная, и подходить к ней с бухты-барахты нельзя ни в коем случае.
В тот день совещание закончилось всем и ничем – решили реализовать всё разом (никто не хотел брать на себя ответственность отказа, т.к. не понимал зачем эти метрики нужны другому человеку).
Иван решил подготовить своё видение метрик DevOps, причём сделать так, чтобы каждая метрика была в нём обоснована, имела конкретную цель, несла пользу и была понятна.
Вот, что у него получилось…
[Иллюстрированное] Руководство по устройству сети в Kubernetes. Часть 3
5 мин
Перевод
Прим. перев.: Эта статья продолжает цикл материалов о базовом устройстве сетей в Kubernetes, что описывается в доступной форме и с наглядными иллюстрациями (впрочем, конкретно в этой части иллюстраций уже практически не оказалось). Переводя две предшествующие части этого цикла, мы объединили их в одну публикацию, в которой рассказывалось о сетевой модели K8s (взаимодействие внутри узлов и между узлами) и оверлейных сетях. Её предварительное чтение желательно (рекомендуется самим автором). Продолжение же посвящено сервисам Kubernetes и обработке исходящего и входящего трафика.
NB: Текст автора для удобства дополнен ссылками (преимущественно — на официальную документацию K8s).
NB: Текст автора для удобства дополнен ссылками (преимущественно — на официальную документацию K8s).
ChatOps в GitLab будет доступен всем
2 мин
Перевод
ChatOps со всем своим функционалом станет бесплатным — это наш вам подарок на праздники.
Эффективная разработка и сопровождение Ansible-ролей
11 мин
Ansible — система, которая решает различные задачи автоматизации, включая конфигурирование, резервное копирование и деплой проектов. Систему приятно использовать для написания сценариев автоматизации от простого окружения до крупного проекта. В сценариях важную роль играют playbooks и роли — структурированные playbooks.
Ansible не волшебная таблетка, и помогает только на первых порах. Когда проект растет, становится сложно поддерживать разросшееся количество ролей. Помогает решить проблему механизм непрерывной поставки для ролей.
Как раз об этом расшифровка доклада Александра Харкевича на DevOps Conf Russia. В докладе: разработка Ansible-ролей через CI, механизм разработки публичных ролей и публичных ролей с тестовыми прогонами в приватной инфраструктуре. А еще в докладе нет вывода.
Ansible не волшебная таблетка, и помогает только на первых порах. Когда проект растет, становится сложно поддерживать разросшееся количество ролей. Помогает решить проблему механизм непрерывной поставки для ролей.
Как раз об этом расшифровка доклада Александра Харкевича на DevOps Conf Russia. В докладе: разработка Ansible-ролей через CI, механизм разработки публичных ролей и публичных ролей с тестовыми прогонами в приватной инфраструктуре. А еще в докладе нет вывода.
Проверяем RBAC в Kubernetes
3 мин
Перевод
Одно дело обезопасить кластер Kubernetes, а вот поддерживать защиту — задачка та еще. Впрочем, в Kubernetes добавилось новых средств: теперь выполнять и то, и другое намного проще.
Ближайшие события
Представляем библиотеку kubedog для слежения за ресурсами Kubernetes
6 мин
Рады анонсировать новую Open Source-разработку компании «Флант» для DevOps-специалистов и не только — kubedog. Это написанная на Go библиотека и CLI на её основе для отслеживания событий ресурсов Kubernetes и сбора их логов.
На данный момент библиотека поддерживает слежение за следующими ресурсами: Pod (и Container), Job, Deployment, StatefulSet и DaemonSet. События и логи передаются через callback’и.
На данный момент библиотека поддерживает слежение за следующими ресурсами: Pod (и Container), Job, Deployment, StatefulSet и DaemonSet. События и логи передаются через callback’и.
Сам себе devops или настраиваем Nginx прокси для Apache Tomcat на Ubuntu за 5 минут c https и firewall'ом
3 мин
Туториал
Я не админ, но иногда возникают задачи, которые проще (и интереснее) решать самому чем кому-то делегировать.
Изредка у нас появляется необходимость «поднять» servlet контейнер (чаще всего Apache Tomcat) и настроить для него проксирование, ssl termination (а проще говоря https) и все это прикрыть firewall'ом (оставив наружу только ssh и http/https).
Так получилось, что за последнюю неделю я эту задачу решал трижды (так стали звезды, а до этого — года два назад) и этот опыт трансформировался в сей небольшой опус.
Бесплатный PVS-Studio для тех, кто развивает открытые проекты
3 мин
В канун празднования нового 2019 года команда PVS-Studio решила сделать приятный подарок всем контрибьюторам open-source проектов, хостящихся на GitHub, GitLab или Bitbucket. Им предоставляется возможность бесплатного использования статического анализатора PVS-Studio для развития открытых проектов.
Интенсив по Kubernetes: о работе саппортов
3 мин
1-3 февраля пройдёт Слёрм-3, интенсив по Kubernetes. Анонс и программа тут.
Сегодня расскажу немного о внутренней кухне: как мы помогаем студентам справляться с практикой и что из этого получается. Заодно будущие участники поймут, чего ждать от поддержки.
Я сам 2-3 раза в год прохожу платные курсы, всегда беру варианты с практикой, и очень редко доделываю ее до конца. Для меня ситуация выглядит, как если бы я заказал в ресторане килограммовый стейк: съел, сколько мог, остальное оставил на тарелке. Но в тех, кто едет на Слёрм, хотелось бы запихнуть всю порцию.
На первом Слёрме мы отнеслись к практике спокойно, мол, мы даем задания, а участники справляются как могут. И это привело бы к катастрофе, если бы в аудитории не нашлось инициативных и талантливых парней: «15 минут назад я писал в чат о проблеме, я ее уже решил сам и помог еще пятерым».
Поэтому на втором Слёрме кроме трех спикеров со студентами работал десяток саппортов: системных администраторов из команды Southbridge.
Лучшие доклады JPoint 2018: Java/JVM и её перформанс, Kotlin, Spring, Docker
11 мин
Мы уже выложили на YouTube видеозаписи докладов JPoint 2018 и специально для хаба Java на Хабре сделали традиционную подборку самых лучших из них по мнению посетителей конференции.
Как обычно, наверху «младшие» доклады, в конце — с самым высоким рейтингом. Конечно, это не значит, что один доклад намного хуже другого: если изменить методику расчета, места могут легко поменяться. В реальности, мы её и изменили, теперь используется «soft quorum» вариант рейтинга, учитывающий количество присутствовавших на докладе участников. Этот подход имеет свои минусы (например, на кейноут приходит больше людей, чем на обычный доклад, просто потому что у аудитории нет выбора), но в целом даёт более качественную картину произошедшего.
Под катом — и видеозаписи лучших докладов, и ссылки на их презентации, и короткие описания, и ссылка на полный плейлист.
О трех компонентах необходимых для успешной работы IT
2 мин
Этот короткий пост является важным дополнением к циклу статей «Как взять сетевую инфраструктуру под свой контроль». Содержание всех статей цикла и ссылки можно найти здесь.
Если вы попробуете применить описанные в этой статье процессы и решения в своей компании, то вы осознаете, что для вас это может не работать.
Например, давайте возьмем процесс по предоставлению доступов.
Чтобы “запустить” этот процесс вам придется сделать следующее
И как убедить этих людей делать достаточно нудную, ответственную и по большому счету непрофильную работу? Кстати говоря, вы не являетесь для них начальником.
Aргументы целесообразности и разумности могут не работать, потому что для других это может и не казаться таким разумным. Понятно, что обычно это не ваша обязанность — все это организовывать, достаточно убедить руководство. Но штука в том, что если это будет сделано вопреки желанию сотрудников, то это может привести к конфронтации и политическим играм. И это, конечно, будет мешать эффективной работе.
Мне кажется очевидным, что если у вас команда профессионалов, то решения, предполагающие совместные действия, лучше принимать сообща и вместе находить лучшее. Но для этого должно присутствовать что-то еще, не только хорошее техническое знание и знание, какой поцесс для этого нужен.
Почему это не работает?
Если вы попробуете применить описанные в этой статье процессы и решения в своей компании, то вы осознаете, что для вас это может не работать.
Например, давайте возьмем процесс по предоставлению доступов.
Чтобы “запустить” этот процесс вам придется сделать следующее
- договориться, чтобы все тикеты шли к вам через другие технические отделы
- сделать так, чтобы эти отделы согласились протоколировать все проходящие через них запросы
- обязать руководителей нетехнических подразделений следить за актуальностью этих списков доступов
И как убедить этих людей делать достаточно нудную, ответственную и по большому счету непрофильную работу? Кстати говоря, вы не являетесь для них начальником.
Aргументы целесообразности и разумности могут не работать, потому что для других это может и не казаться таким разумным. Понятно, что обычно это не ваша обязанность — все это организовывать, достаточно убедить руководство. Но штука в том, что если это будет сделано вопреки желанию сотрудников, то это может привести к конфронтации и политическим играм. И это, конечно, будет мешать эффективной работе.
Мне кажется очевидным, что если у вас команда профессионалов, то решения, предполагающие совместные действия, лучше принимать сообща и вместе находить лучшее. Но для этого должно присутствовать что-то еще, не только хорошее техническое знание и знание, какой поцесс для этого нужен.
Shell-скрипты в Ansible
8 мин
Предположим, что заказчик попросил вас помочь с переносом скрипта для развертывания централизованного файла sudoers на серверах RHEL и AIX.
Что же, это вполне распространенный сценарий, и на его примере можно продемонстрировать использование расширенных возможностей Ansible, а также того, как меняется подход – от скрипта, который выполняет некую задачу, к идемпотентному (без внесения изменений) описанию и контролю за соблюдением состояния экземпляра.
Что же, это вполне распространенный сценарий, и на его примере можно продемонстрировать использование расширенных возможностей Ansible, а также того, как меняется подход – от скрипта, который выполняет некую задачу, к идемпотентному (без внесения изменений) описанию и контролю за соблюдением состояния экземпляра.