Привет, Хабр!

Я работаю в команде Tinkoff, которая занимается разработкой собственного центра нотификаций. По большей части я разрабатываю на Java с использованием Spring boot и решаю разные технические проблемы, возникающие в проекте.

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

В качестве замены нам предложили Apache Kafka, которая обладает высоким потенциалом масштабирования, но, к сожалению, требует практически индивидуального подхода к конфигурированию для разных сценариев. Кроме того, механизм at least once delivery, работающий в Kafka по умолчанию, не позволял поддерживать необходимый уровень консистентности из коробки. Далее я поделюсь нашим опытом конфигурации Kafka, в частности расскажу, как настроить и жить с exactly once delivery.

Когда я разговариваю с Linux инженерами и говорю им о проблемах Kubernetes кластера на Windows, на меня смотрят очень подозрительно. Некоторые даже не верят что это законно такое бывает. Контейнеры на Windows не так распространены и востребованы, как на Linux. Но я думаю, что поговорить об этой теме стоит, хотя бы для того, что бы понимать общую концепцию и основные отличия контейнеров Windows и Linux. Первой записью я пройдусь по полотну широкой кистью, а затем, в последующих постах, попробую постепенно углубиться в нюансы.

Nemesida WAF Free — бесплатная версия Nemesida WAF, обеспечивающая базовую защиту веб-приложения от атак класса OWASP на основе сигнатурного анализа. Nemesida WAF Free имеет собственную базу сигнатур, выявляет атаки на веб-приложения при минимальном количестве ложных срабатываний, обновляется из Linux-репозитория, устанавливается и настраивается за несколько минут, не требует компиляции и может быть подключена к уже установленному NGINX версии 1.12.2 или выше.


Что может произойти, если не следить за безопасностью и не использовать WAF

Некоторое время назад мы анонсировали поддержку Nemesida WAF Free для NGINX Mainline и Plus версий (раньше поддерживалась только Stable ветка). Решив на этом не останавливаться, мы добавили во Free-версию функционал отправки выявленных атак в личный кабинет.

Доброго времени суток, Хабравчане.  Я работаю в компании Veeam Software и являюсь одним из разработчиков нашего решения для бэкапа линукс систем. По роду занятий мне довелось столкнуться с BTRFS. Совсем недавно она перешла из статуса «еще не пригодно» в статус «стабильна». И пока её первые пользователи в сети обсуждали проблемные места и вопросы стабильности, мы в Veeam тыкали её палочкой и пытались бэкапить. Получалось, мягко говоря, не очень — слишком уж она другая, не похожая на традиционные файловые системы. Пришлось изучить немало аспектов и собрать множество граблей, прежде чем научились с ней работать. В процессе изучения BTRFS сумела произвести на меня впечатление как в хорошем смысле, так и не очень. Уверен, она не оставит равнодушным ни одного айтишника из мира линукс: одни будут плеваться, другие восхвалять.

Если вы слышали об этой файловой системе, но не знаете, зачем она, интересуетесь подробностями или ищете, с чего начать знакомство с ней — приглашаю под кат.

Привет, Хабр! Предлагаю вашему вниманию перевод статьи основателя сервиса Meetspaceapp Nick Gauthier «Building Minimal Docker Containers for Go Applications».

Время чтения: 6 минут

Существует множество, как официальных, так и поддерживаемых сообществом контейнеров для различных языков программирования (включая Go). Но эти контейнеры могут быть довольно большими. Давайте сперва сравним стандартные методы создания контейнеров для Go-приложений, а затем я покажу способ создания крайне маленьких статических контейнерезированных Go-приложений

Часть 1: Наше «приложение»

Для тестирования нам потребуется какое-нибудь маленькое приложение. Давайте будем фетчить google.com и выводить размер HTML.

package main

import (
    "fmt"
    "io/ioutil"
    "net/http"
    "os"
)

func main() {
    resp, err := http.Get("https://google.com")
    check(err)
    body, err := ioutil.ReadAll(resp.Body)
    check(err)
    fmt.Println(len(body))
}

func check(err error) {
    if err != nil {
        fmt.Println(err)
        os.Exit(1)
    }
}

Если мы запустимся, то получим только какое-то число. У меня вышло около 17К. Я целенаправленно решил использовать SSL, но причину объясню позднее.

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

Нерешенная проблема, на которой мы остановились в прошлый раз, состоит в том, что неизвестно, с какого момента можно начинать проигрывание журнальных записей при восстановлении. Начать с начала, как советовал Король из Алисы, не получится: невозможно хранить все журнальные записи от старта сервера — это потенциально и огромный объем, и такое же огромное время восстановления. Нам нужна такая постепенно продвигающаяся вперед точка, с которой мы можем начинать восстановление (и, соответственно, можем безопасно удалять все предшествующие журнальные записи). Это и есть контрольная точка, о которой сегодня пойдет речь.

Контрольная точка

Каким свойством должна обладать контрольная точка? Мы должны быть уверены, что все журнальные записи, начиная с контрольной точки, будут применяться к страницам, записанным на диск. Если бы это было не так, при восстановлении мы могли бы прочитать с диска слишком старую версию страницы и применить к ней журнальную запись, и тем самым безвозвратно повредили бы данные.

Всем привет! Специально для студентов курса "Безопасность Linux" мы подготовили перевод официального FAQ проекта SELinux. Нам кажется, что данный перевод может быть полезен не только студентам, поэтому делимся им с вами.

Мы попытались ответить на некоторые наиболее часто задаваемые вопросы о проекте SELinux. В настоящее время вопросы разделены на две основные категории. Все вопросы и ответы приведены на странице FAQ.

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

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

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

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

Сегодня мы рассмотрим протокол BGP. Не будем долго говорить зачем он и почему он используется как единственный протокол. Довольно много информации есть на этот счет, например тут.

Итак, что такое BGP? BGP — это протокол динамической маршрутизации, являющийся единственным EGP( External Gateway Protocol) протоколом. Данный протокол используется для построения маршрутизации в интернете. Рассмотрим как строится соседство между двумя маршрутизаторами BGP.


Рассмотрим соседство между Router1 и Router3. Настроим их при помощи следующих команд:

Исторически сложилось, что sudo права регулировались содержимым файлов из /etc/sudoers.d и visudo, а авторизация по ключам велась с использованием ~/.ssh/authorized_keys. Однако с ростом инфраструктуры возникает желание управлять этими правами централизованно. На сегодняшний день вариантов решения может быть несколько:

• Система управления конфигурацией — Chef, Puppet, Ansible, Salt
• Active Directory + sssd
• Разнообразные извращения в виде скриптов и ручного редактирования файлов

На мой субъективный взгляд, оптимальным вариантом централизованного управления является все-таки связка Active Directory + sssd. Преимущества данного подхода вот в чем:

• Действительно Единый централизованный каталог пользователей.
• Раздача прав sudo сводится к добавлению пользователя в определенную группу безопасности.
• В случае различных Linux-систем возникает необходимость вводить дополнительные проверки на определение ОС при использовании систем конфигурации.

Сегодняшняя сюита будет посвящена именно связке Active Directory + sssd для управления правами sudo и хранением ssh ключей в едином репозитории.
Итак, зал застыл в напряженном молчании, дирижер поднял палочку, оркестр приготовился.
Поехали.

Наша компания с 2008 года занимается преимущественно управлением инфраструктурами и круглосуточной технической поддержкой веб-проектов: у нас более 400 клиентов, это порядка 15% электронной коммерции России. Соответственно, на поддержке очень разнообразная архитектура. Если что-то падает, мы обязаны в течение 15 минут это починить. Но чтобы понять, что авария произошла, нужно мониторить проект и реагировать на инциденты. А как это делать?

Я считаю, что в организации правильной системы мониторинга происходит беда. Если бы беды не было, то мой спич состоял из одного тезиса: «Установите, пожалуйста, Prometheus + Grafana и плагины 1, 2, 3». К сожалению, теперь так не работает. И главная проблема заключается в том, что все продолжают верить во что-то такое, что существовало в 2008 году, с точки зрения программных компонентов.

В отношении организации системы мониторинга я рискну сказать, что… проектов с грамотным мониторингом не существует. И ситуация настолько плохая, если что-то упадёт, есть риск, что это останется незамеченным — все ведь уверены, что «всё мониторится».
Возможно, всё мониторится. Но как?

Все мы сталкивались с историей наподобие следующей: работает некий девопс, некий админ, к ним приходит команда разработчиков и говорит — «мы зарелизились, теперь замониторь». Что замониторь? Как это работает?

Ок. Мониторим по старинке. А оно уже изменяется, и выясняется, что ты мониторил сервис А, который стал сервисом B, который взаимодействует с сервисом C. Но команда разработчиков тебе говорит: «Поставь софт, он же должен все замониторить!»

Так что изменилось? — Всё изменилось!

KlusterKit: набор инструментов с открытым исходным кодом для упрощения деплоев Kubernetes и работы в физически изолированных локальных средах

Сегодня мы с радостью объявляем, что Platform9 открывает исходные коды Klusterkit, набора из трех инструментов, по лицензии Apache v2.0 на GitHub.

Наши клиенты выкатывают ПО в частных дата-центрах, которые часто не подключены к интернету (по соображениям безопасности или по другим причинам). Эти крупные компании хотят использовать преимущества Kubernetes и модернизировать свои приложения и при этом выкатывать их в разных дата-центрах, у которых нередко нет связи с внешним миром. И тут на помощь приходит Klusterkit, который упрощает поставку и управление кластерами K8s в физически изолированных средах.

В Klusterkit входит три независимых инструмента, которые можно использовать вместе или по отдельности для управления жизненным циклом production-кластера Kubernetes:

1. etcdadm, CLI для упрощенного управления кластером etcd.
2. nodeadm, CLI для администрирования нод, который дополняет kubeadm и развертывает зависимости, нужные kubeadm.
3. cctl, инструмент управления жизненным циклом кластера, который принимает Cluster API из сообщества Kubernetes и использует nodeadm и etcdadm, чтобы без лишних хлопот поставлять и поддерживать высокодоступные кластеры Kubernetes в локальных и в том числе физически изолированных средах.

Вместе эти три инструмента выполняют следующие задачи:

Значимо изменить маршализацию структуры в json можно только через метод MarshalJSON(), написав там полную реализацию маршализации. Как именно? На это документация Go ни ответов, ни рекомендаций не даёт, предоставляя, так сказать, полную свободу. А как воспользоваться этой свободой так, чтобы не нагородить кучу костылей, перенеся всю логику в MarshalJSON(), и потом не перепиливать эту бедную постоянно разрастающуюся функцию при очередных кастомизациях json?

Решение на самом деле простое:

1. Будь честен (честна).

(Второго пункта не будет, первого хватит.)

Сегодня поговорим о том, как избавиться от документации, которая не работает, описывает какое-то легаси, не организована, не соответствует идентичности вашего бренда, да что там — просто плохой документации. Чтобы затем подготовить и реорганизовать хорошую, валидную, логично организованную и соответствующую идентичности бренда документацию. И как только вы сможете избавиться от документации — все станет радужно и прекрасно.



Под катом перевод доклада Александры Уайт, технического писателя из компании Google, на конференции Write the Docs Prague 2018. А уже через неделю 26 апреля 2019 Александра выступит на нашей конференции KnowledgeConf с докладом «How to create compelling multimedia documentation». Александра расскажет, как встроить мультимедиа форматы (видео, аудио, gif) в процесс создания артефактов и упаковки знаний, когда мультимедиа форматы подойдут лучше всего, а когда не будут работать, как измерять эффективность мультимедиа артефактов и преодолевать их ограничения.

Всем привет!

В данной статье, описаны шаги, которые необходимо выполнить для добавления к вашему WDS, возможности загрузки в режиме UEFI.

Т.е. инструкция в данной статье, предполагает, что у вас уже имеется, примерно следующая конфигурация:

1. Windows Server 2012R2 (или новее)
2. Полностью настроенный DHCP для работы с WDS
3. Собственно сам WDS
4. IIS
5. Виртуальная машина или ПК с Ubuntu

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

Предисловие

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

Помогли мне кстати тогда вот эти статьи:
Добавляем WDS универсальности
Загрузочное меню PXE с System Center Configuration Manager

Материал, перевод которого мы публикуем сегодня, предназначен для тех, кто хочет освоить командную строку Linux. Умение эффективно пользоваться этим инструментом позволяет экономить немало времени. В частности, речь здесь пойдёт о командной оболочке Bash и о 21 полезной команде. Также мы поговорим о том, как пользоваться флагами команд и псевдонимами Bash, которые позволяют ускорить ввод длинных инструкций.



→ Также читайте в нашем блоге цикл публикаций про bash-скрипты

Аннотация: Уровни зрелости ИТ-инфраструктуры предприятия.
Описание преимуществ и недостатков каждого уровня в отдельности.

Прим. перев.: Первая часть этого цикла была посвящена знакомству с возможностями Istio и их демонстрации в действии. Теперь же речь пойдёт про более сложные аспекты конфигурации и использования этого service mesh, а в частности — про тонко настраиваемую маршрутизацию и управление сетевым трафиком.

Напоминаем также, что в статье используются конфигурации (манифесты для Kubernetes и Istio) из репозитория istio-mastery.

Знакомьтесь — Kapitan. Он поможет вам навести красоту и порядок в конфигурации Kubernetes.

Kapitan зарабатывает репутацию на отзывах довольных пользователей, и потому обходится без обширной документации и дорогого маркетинга. У нас достаточно звезд и пара упоминаний от блогеров и проповедников Kubernetes. Kapitan даже стал главным героем целой главы в книге. Что самое главное, он привлек внимание нескольких перспективных компаний, ведь Kapitan как никто другой умеет распутывать конфигурацию, завязанную морским узлом.

На kubernetes.slack.com #kapitan успел собрать небольшое, но преданное сообщество (присоединяйтесь!), поэтому мы гордимся своей работой :)

Многие до сих пор считают, что Kapitan — это смесь jsonnet и jinja, но они упускают суть.
В этом посте я расскажу, как Kapitan управляет деплоями Kubernetes, но вообще-то он способен не только на это. Это важно: Kapitan универсален и не зациклен на одном Kubernetes. Kubernetes — это просто один из множества вариантов использования.

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