Услуги DevOps

Что такое методология DevOps и в каких случаях она нужна?

DevOps позволяет построить удобный сервис обслуживания программного продукта, основанный на интеграции системных администраторов, тестировщиков и программистов.

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

Также хорошей практикой DevOps является использование инструментов облегчающих построение подобных распределенных систем. Названия Docker, Jenkins, Gitlab, TeamCity, Ansible давно употребляются вместе с DevOps. Использование этих инструментов позволяет значительно упростить создание удобной в использовании и работающей в автоматическом режиме системы.

Создание удобной для поддержания и управления инфраструктуры одна из основных целей при построении системы удобной интеграции и обслуживания. В настоящее время для этого очень хорошо подходят и используются разные среды оркестрации Docker Swarm, Kubernetes, Rancher. Использование разных сред под разные запросы и задачи позволяет создавать гибкую среду для управления вашими приложениями.

Основным лицом в подобного рода структуре является инженер DevOps, который осуществляет связь между всеми заинтересованными лицами процесса доставки ПО в продакшен. Эта система позволяет удобно описать каждый из этапов цикла. Главная цель и смысл в построении прозрачной и удобной инфраструктуры для разработки и сопровождении ПО.

 Услуги DevOps:

  • Оценка проекта, выбор наилучшей системы для создания CI
  • Установка и настройка Gitlab, Jenkins, Teamcity и других инструментов DevOps
  • Оркестрация инфраструктуры с помощью ansible, описание плейбуками
  • Разработка системы деплоя, внедрение CI/CD
  • Внедрение удобной среды Docker, Swarm, Kubernetes

Сборка openssh с поддержкой авторизации через LDAP

На прошлых выходных вышла новая версия дистрибутива Debian 8 (Jessie), нового там много, поэтому впереди довольно много обновлений систем предстоит. В связи с этим решил заранее собрать версию ssh сервера, которая у меня используется в разных местах – она умеет работать с пользователями из LDAP. В этой статье я коснусь только самого процесса сборки, сам процесс настройки системы под подобную авторизацию я как-нибудь опишу позже. А сейчас о том как быстро и безболезненно пропатчить openssh-server на Debian 8 с патчем LPK.

Сам патч разработан давно в рамках LPK progect – http://code.google.com/p/openssh-lpk/ , есть несколько форков и продолжений этого патча под разные версии openssh. Я воспользовался одним из этих форков для предыдущего патча на Debian 7, когда пришло время я взял его же. Скачать его можно по ссылке https://github.com/takkeybook/openssh-lpk. Небольшую сложность, которая заключается в том что он для openssh-6.6p1 не так сложно обойти. Итак, предполагается что у вас уже есть среда с Debian 8 где вы будете проводить сбору. Выкачиваем исходники:

cd /usr/src ; apt-get source openssh-server

Скачиваем патч:

git clone https://github.com/takkeybook/openssh-lpk.git

Переименуем его для удобства и положим к остальным патчам для пакета:

cp openssh-lpk-6.6p1-0.3.14.patch /usr/src/openssh-6.7p1/debian/patches/openssh-lpk-6.7p1-0.3.14.patch

Добавляем в /usr/src/openssh-6.7p1/debian/patches/series этот патч

В самом патче меняем все упоминания 6.6p1 на 6.7p1. После этого пушим изменения о новых патчах

cd /usr/src/openssh-6.7p1/ ; quilt push ; quilt refresh

Доставляем необходимые пакеты для сборки если они не были установлены до этого:

apt-get build-dep openssh-server

Прописываем изменения в changelog чтобы у вас получился новый пакет с изменениями. Для этого воспользуемся утилиткой dch.

dch -i

Пишем, что-нибудь про изменения которые были внесены чтобы не забыть, например

Add LPK patch for working with LDAP

Теперь можно собирать пакет:

dpkg-buildpackage -us -uc

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

Настройка OpenVPN с авторизацией через LDAP

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

Для начала приведу общий конфиг для openvpn остановивлюсь на тех вещах которые нужны именно для нормальной работы opnevpn+ldap

tmp-dir /tmp
local 142.2.44.55
port 2000
proto tcp-server
tcp-queue-limit 256
bcast-buffers 4096
duplicate-cn
dev tun0
ca /etc/openvpn/keys/ca.crt
cert /etc/openvpn/keys/local.crt
client-cert-not-required
username-as-common-name
key /etc/openvpn/keys/local.key
dh /etc/openvpn/keys/dh2048.pem
server 10.30.0.0 255.255.255.0
push "route 10.11.0.0 255.255.0.0"
push "dhcp-option DNS 10.11.0.1"
push "dhcp-option DOMAIN example.local"
push "sndbuf 393216"
push "rcvbuf 393216"
tls-server
tls-auth /etc/openvpn/keys/ta.key 0
tls-timeout 120
auth MD5
cipher AES-256-CBC
keepalive 10 120
max-clients 100
user nobody
group nogroup
persist-key
persist-tun
script-security 3 execve
status /var/log/openvpn/openvpn-status.log
log /var/log/openvpn/openvpn.log
verb 4
plugin /usr/lib/openvpn/openvpn-auth-ldap.so "auth-ldap.conf"

В целом все как при обычном конфигурировании openvpn, есть небольшие только отличия

username-as-common-name – меняет авторизацию по common name из сертификата на авторизацию по логину и паролю, то что именно нам и надо.

plugin /usr/lib/openvpn/openvpn-auth-ldap.so “auth-ldap.conf” – подключает в качестве плагина openvpn-auth-ldap.so, который даест возможность вытаскивать из LDAP данные пользователя и использовать их для прохождения авторизации. На дебиане он ставиться довольно просто:

apt-get install openvpn-auth-ldap

В основном конфиге все, более добавлять ничего не надо. Есть еще дополнительный конфиг auth-ldap.conf где и осуществляется вся магия авторизации через LDAP.

URL ldap://10.11.0.2
BindDN cn=user,dc=example
Password pass
Timeout 15

BaseDN “ou=people,dc=example”
SearchFilter “(&(uid=%u)(attr1=vpn))”
RequireGroup false

Тут указаны данные к какому LDAP серверу подсоединяться

URL ldap://10.11.0.2

с какими правами работать

BindDN cn=user,dc=example , Password pass

и в какой директории искать

BaseDN “ou=people,dc=example”

Так же указан фильтр по которому будет производиться выборка

SearchFilter “(&(uid=%u)(attr1=vpn))”

это значит что будет проводиться поиск по указанному пользователю и если у него есть атрибут attr1=vpn, что позволяет ограничить в директории пользователей на тех кому нужен доступ по VPN и кому нет, так же можно разграничить доступ по разным VPN.

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

URL ldap://10.11.0.2
BindDN cn=user,dc=example
Password pass
Timeout 15

BaseDN “ou=people,dc=example”
SearchFilter “(uid=%u)”
RequireGroup true

BaseDN “cn=openvpn,ou=groups,dc=example”
SearchFilter “(cn=openvpn)”
MemberAttribute memberUid

 

Добавляется секция с поиском в группе указанного пользователя. Теперь для предоставления прав на доступ достаточно добавить пользователя в указанную группу или удалить если он там больше не нужен. Вот в общем и все, надеюсь эта статья будет вам полезна.

Универсальный резолвер – unbound

Сегодня я бы хотел поведать еще об одном важном компоненте IT инфрастуктуры таким каким несомненно является резолвер. И в качестве такого резолвера я бы хотел бы представить вам очень быстрый и надежный сервер для кеширования ДНС – unbound. Пользуюсь я им давно и его возможности и производительность во всем меня устраивает. То же самое касается и простоты настройки этого демона. В целом конфигурационный файл его снабжен достаточно подробными пояснения так, что разобраться во всем хозяйстве не сложно, но я на некоторых моментах все-таки остановлюсь

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

server:
#Указывает как подробно будут идти записи в логи, есть вариант 0 - совсем мало, 1 - чуть побольше
verbosity: 1
#Интервал сбора статистики в секндах
statistics-interval: 30
# Расширенная статистика, по умолчанию выключена, влияет на скорость работы, нужна только при каких-то отладочных моментах
# extended-statistics: no
# Количество тредов запускаемых при старте демона
num-threads: 4

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

Дальше у нас немного настроек по интерфейсам, на каких адресах висеть и какие порты слушать:

# По умолчанию работает на (127.0.0.1 и ::1).
# Можно указать 0.0.0.0 и ::0 тогда будет работать на всех имеющихся адресах.
# Я указываю конкретные адреса на которых резолверу можно работать, так удобнее и надежнее, по одному интерфейсу на строчку
interface: 127.0.0.1
interface: 10.11.12.15
interface: 10.12.13.16
interface: 122.3.22.131
# interface: 192.0.2.154@5003
# interface: 2001:DB8::5
# Экспериментальная опция, включающая подстановку адреса источника в ответ, работает не везде, выключаю, поскольку не особо и надо
interface-automatic: no
# Можно указать порт для работы отличный от дефолтного 53, по сути это скорее вредно чем полезно и может пригодится только в очень малом количестве случаев
# port: 53
# Указываем адрес с которого будут уходить запросы к внешним ДНС, поскольку будут приходить туда же стоит указывать внешний адрес
outgoing-interface: 122.3.22.131
# outgoing-interface: 2001:DB8::5
# outgoing-interface: 2001:DB8::6

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

# Включаем IPv4, "yes" или "no".
do-ip4: yes
# Включаем IPv6, "yes" или "no".
do-ip6: no
# Включаем UDP, "yes" или "no".
do-udp: yes
# Включаем TCP, "yes" или "no".
do-tcp: yes
# Запускаем как демона, "yes" or "no".
do-daemonize: yes

# Указываем с каких адресов можно делать запросы через этот резолвер, указываем тех кому действительно можно
access-control: 0.0.0.0/0 refuse
access-control: 127.0.0.0/8 allow
access-control: 10.0.0.0/8 allow
access-control: 122.3.22.0/22 allow
# access-control: ::1 allow
# access-control: ::ffff:127.0.0.1 allow

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

# Полезная довольно опция, в которой можно указать какие зоны обслуживаются локально и с помощью опции local-data указать значения тех или иных записей
# При этом с помощью разных опций указать что делать с запросами для этих зон
# o deny - сбрасывает все запросы.
# o refuse - отбивает с ошибкой.
# o static - отдает статически прописанные значения которые есть в local-data, на все остальное выдает что нет данных
# o transparent - отдает значения в local data, но и нормально резолвит остальные записи
# o redirect - перенаправляет запросы на другой домен.
# o nodefault - используется для резолвинга AS112 зон.
local-zone: "grombon.local." transparent
local-zone: "10.10.in-addr.arpa." transparent
local-zone: "lookup.net." transparent
# Примеров с использования local-data может быть несколько
# local-data: "mycomputer.local. IN A 192.0.2.51"
# local-data: 'mytext.local TXT "content of text record"'
# local-data: "adserver.example.com A 127.0.0.1"
# local-zone: "example.com" redirect
# local-data: "example.com A 192.0.2.3"
# local-data-ptr: "192.0.2.3 www.example.com"

Следующие несколько параметров дают возможность удаленного управления unbound, если вам это действительно нужно, то разберетесь сами тут все не так уж и сложно

В конце конфигурационного файла есть возможность для указания зон запросы для которых нужно в обязательном порядке перенаправлять на другие сервера

# Перенаправляет все запросы для зоны на указанный адрес
stub-zone:
name: "lookup.net"
stub-addr: 165.45.55.15
# форвардит все запросы на указанные адреса неймсерверов, очень схожий с предыдущей опцией параметр.
forward-zone:
name: "example.ru"
forward-addr: 165.45.55.15
forward-addr: 165.45.54.15
forward-addr: 165.45.53.15
forward-zone:
name: "grombon.local"
forward-addr: 165.45.55.15
forward-addr: 165.45.54.15
forward-addr: 165.45.53.15
forward-zone:
name: "10.10.in-addr.arpa"
forward-addr: 165.45.55.15
forward-addr: 165.45.54.15
forward-addr: 165.45.53.15

В целом разобраться во всем не так уж и сложно, сложностей никаких. В работе сервер неприхотлив, надежен и требует минимума внимания. Настроил и забыл. То что надо.

Настройка TLS для LDAP

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

Как и прежде, все настройки мы храним с самом LDAP и реплицируем между всем серверами реплики. В качестве ключей будем использовать самоподписные ключи сгенерированные с помощью утилит из набора GNU TLS. Ключи сделанные через openssl работать не будут, так что пользоваться придется certtool, что совсем не сложно. Для начала установим набор утилит:

apt-get install gnutls-bin

Теперь можно сгенерировать корневые сертификаты для нашего самоподписного сертификата, пока я этого не сделал, получал подобную ошибку:

slapd TLS: can't connect: A TLS packet with unexpected length was received..

Поэтому делаем набор ключ и сертификат для корневого сертификата и им подписываем сертификат для непосредственно рабочей пары:

certtool --generate-privkey --outfile ca.key
certtool --generate-self-signed --load-privkey ca.key --outfile ca.crt

Генерим рабочую пару:

certtool --generate-privkey --outfile ldap.prod.local.key
certtool --generate-certificate --load-privkey ldap.prod.local.key --outfile ldap.prod.local.crt --load-ca-certificate ca.crt --load-ca-privkey ca.key

Кладем все полученные сертификаты и приватный ключик в папочку где они будут доступны для сервера, например в /etc/ldap/ssl. Добавляем владельца и группу:

chown -R openldap:openldap /etc/ldap/ssl

Вносим изменения в конфиг, добавляя туда информацию о ключах с помощью следующих строчек

dn: cn=config
add: olcTLSCACertificateFile
olcTLSCACertificateFile: /etc/ldap/ssl/ca.crt
-
add: olcTLSCertificateKeyFile
olcTLSCertificateKeyFile: /etc/ldap/ssl/ldap.prod.local.key
-
add: olcTLSCertificateFile
olcTLSCertificateFile: /etc/ldap/ssl/ldap.prod.local.crt

Теперь можно перезапустить сервер с работой по шифрованному протоколу, для этого идем в /etc/default/slapd и в строчке

SLAPD_SERVICES="ldap://server1.prod.local ldapi:///"

Добавляем еще один биндинг

ldaps://server1.prod.local, так чтобы полная строчка стала выглядеть так:

SLAPD_SERVICES="ldap://server1.prod.local ldapi:/// ldaps://server1.prod.local"

Делаем это на каждом из серверов и перезапускаем службу:

/etc/init.d/slapd restart

Теперь демон будет, помимо 389 порта, еще доступен на 636 порту, не забудьте открыть его в файерволе. Для того чтобы помимо обычных запросов, шифровались и запросы по реплике, то при конфигурировании реплики надо указывать ключик starttls=yes, при этом остальные параметры остаются без изменений, в общем конфиг для репликации конфигов будет выглядеть таким вот образом:

dn: olcDatabase={0}config,cn=config
changetype: modify
add: olcSyncRepl
olcSyncRepl: rid=001 provider=ldap://server1.prod.local binddn="cn=admin,cn=config"
bindmethod=simple credentials=ck3u8gj3
searchbase="cn=config" type=refreshAndPersist
retry="5 5 300 5" timeout=1 starttls=yes
olcSyncRepl: rid=002 provider=ldap://server2.prod.local binddn="cn=admin,cn=config"
bindmethod=simple credentials=ck3u8gj3
searchbase="cn=config" type=refreshAndPersist
retry="5 5 300 5" timeout=1 starttls=yes
-
add: olcMirrorMode
olcMirrorMode: TRUE

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