Это вторая публикация, созданная по мотивам моих выступлений на конференциях. Первая была общей и посвящена обзору практик Continuous Delivery с Docker. Новая основана на более прикладном докладе «Собираем Docker-образы быстро и удобно», который прозвучал 8 ноября на конференции HighLoad++ 2016 в секции «DevOps и эксплуатация».



Как и в прошлый раз, если у вас есть возможность потратить ~час на видео, рекомендуем посмотреть его полностью (см. в конце статьи). В ином случае — представляем основную суть в текстовом виде.

Что мы хотим от Docker-образов?

Предисловие от переводчика: CockroachDB — достаточно молодая реляционная СУБД с открытым кодом (лицензия Apache 2.0), изначально созданная быть распределённой (с горизонтальным масштабированием «из коробки») и отказоустойчивой. Её авторы из компании Cockroach Labs, созданной в 2015 году, задаются целью «совместить богатство функциональности SQL с горизонтальной доступностью, привычной для NoSQL-решений». Данное руководство написано одним из сотрудников компании-разработчика и опубликовано на сайте облачного провайдера DigitalOcean для того, чтобы познакомить ИТ-специалистов с этой СУБД и продемонстрировать её использование.

Введение

CockroachDB — распределённая СУБД (SQL) с открытым кодом, обеспечивающая согласованность данных, масштабируемость и выживаемость.

Настройка CockroachDB проста: устанавливаете её на нескольких серверах (узлах) и объединяете их в единое целое для совместной работы (кластер). Все узлы кластера действуют «симметрично» и предлагают доступ к одинаковым данным. Если хранилище для данных необходимо увеличить, то при используемой архитектуре достаточно создать новые узлы и присоединить к кластеру.

Артем Каличкин (ЦФТ)

Меня зовут Артем Каличкин, я работаю в компании «Центр Финансовых Технологий», которая занимает лидирующие позиции по производству и разработке программного обеспечения для банковского и финансового сектора. Я занимаю должность директора по сопровождению эксплуатации.

Возможно ли использование практик и подходов DevOps, CD в корпоративной среде? Какие особенности? SPARC + Unix (Solaris)? Вертикальное масштабирование и как следствие — разная конфигурация в бою и на стейдже. Об этом и поговорим.

Про использование Docker и Docker-compose последнее время написано очень много, например рекомендую недавнюю статью на Хабре, если вы до сих пор не прониклись. Это действительно очень удобно, а в связке в ansible особенно. И я его использую везде. От разработки, до автоматического интеграционного тестирования на CI. Про использование в тестировании, тоже писали. Это здорово и удобно. Однако, для локальной разработки, для траблешутинга данных "как в продакшене" или тестирование производительности, на "объёмах близких в продакшену", хочется иметь под рукой образ, содержащий базу, "как в продакшене"!

Соответственно, хочется, чтобы каждый разработчик, приступая к работе над проектом, мог запустить его одной командой, например:

./gradlew dockerRun

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

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

Разумеется мы поговорим о написании Dockerfile для такого образа с данными, и некоторых подводных камнях этого процесса.

Собеседование на английском — дело непростое. Но хорошее планирование и подготовка ключевых моментов сделают этот процесс более приятным и безобидным.

В этой статье я опишу установку и настройку Active/Active кластера на основе Pacemaker, Corosync 2.x и CLVM с использованием разделяемого хранилища. Покажу, как приспособить этот кластер для работы с контейнерами LXC и Docker. Опишу команды для работы с кластером. И припомню те грабли, в которые вляпался, что, надеюсь, облегчит судьбу следующим проходимцам.

В качестве серверных дистрибутивов буду использовать CentOS 7 + epel и актуальные версии пакетов в них. Основной инструмент для работы с Pacemaker-ом будет PCS (pacemaker/corosync configuration system).

Этом цикле статей «Идеальный www кластер», я хочу передать базовые основы построения высокодоступного и высокопроизводительного www решения для нагруженных web проектов для неподготовленного администратора.
Статья будет содержать пошаговую инструкцию и подойдет любому человеку кто освоил силу copy-paste
Ошибки найденые вами, помогут в работе и мне и тем кто будет читать эту статью позже! Так что любые улучшение и правки приветствуются!

Хочу отметить, что эта инструкция родилась в процессе миграции web-систем компании Acronis в высокодоступный кластер. Надеюсь мои заметки будут полезны и для Вас!.

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

На frontend мы будем использоваться связку из двух службы:

keepalived — реализации протокола VRRP (Virtual Router Redundancy Protocol) для Linux. Демон keepalived следит за работоспособностью машин и в случае обнаружения сбоя — исключает сбойный сервер из списка активных серверов, делегируя его адреса другому серверу.

Другими словами, у нас 2 сервера на которых прописано по одному публичному адресу. Если любой из этих серверов падает, то адрес упавшего подхватывается вторым.
Демоны keepalived общаются по протоколу VRRP, посылая друг другу сообщения на адрес 224.0.0.18.
Если сосед не прислал свое сообщение, то по истечению периода он считается умершим и оба адреса обслуживает оставшаяся нода. Как только упавший сервер начинает слать свои сообщения в сеть, все возвращается на свои места

nginx [engine x] — это HTTP-сервер и обратный прокси-сервер, а также почтовый прокси-сервер, написанный Игорем Сысоевым. Уже длительное время он обслуживает серверы многих высоконагруженных российских сайтов, таких как Яндекс, Mail.Ru, ВКонтакте и Рамблер. Согласно статистике Netcraft nginx обслуживал или проксировал 15.08% самых нагруженных сайтов в октябре 2013 года.

Основная функциональность HTTP-сервера

• Обслуживание статических запросов, индексных файлов, автоматическое создание списка файлов, кэш дескрипторов открытых файлов;
• Акселерированное обратное проксирование с кэшированием, простое распределение нагрузки и отказоустойчивость;
• Акселерированная поддержка FastCGI, uwsgi, SCGI и memcached серверов с кэшированием, простое распределение нагрузки и отказоустойчивость;
• Модульность, фильтры, в том числе сжатие (gzip), byte-ranges (докачка), chunked ответы, XSLT-фильтр, SSI-фильтр, преобразование изображений; несколько подзапросов на одной странице, обрабатываемые в SSI-фильтре через прокси или FastCGI, выполняются параллельно;
• Поддержка SSL и расширения TLS SNI.

Другие возможности HTTP-сервера

• Виртуальные серверы, определяемые по IP-адресу и имени;
• Поддержка keep-alive и pipelined соединений;
• Гибкость конфигурации;
• Изменение настроек и обновление исполняемого файла без перерыва в обслуживании клиентов;
• Настройка форматов логов, буферизованная запись в лог, быстрая ротация логов;
• Специальные страницы для ошибок 3xx-5xx;
• rewrite-модуль: изменение URI с помощью регулярных выражений;
• Выполнение разных функций в зависимости от адреса клиента;
• Ограничение доступа в зависимости от адреса клиента, по паролю (HTTP Basic аутентификация) и по результату подзапроса;
• Проверка HTTP referer;
• Методы PUT, DELETE, MKCOL, COPY и MOVE;
• FLV и MP4 стриминг;
• Ограничение скорости отдачи ответов;
• Ограничение числа одновременных соединений и запросов с одного адреса;
• Встроенный Perl.

Целью статьи является дать основные представления о DevOps и практиках, используемых при этой методологии. Тут не будет сложных терминов, конкретных продуктов и road map внедрения DevOps, но, надеюсь, будет интересно ознакомиться.

Bash-скрипты: начало
Bash-скрипты, часть 2: циклы
Bash-скрипты, часть 3: параметры и ключи командной строки
Bash-скрипты, часть 4: ввод и вывод
Bash-скрипты, часть 5: сигналы, фоновые задачи, управление сценариями
Bash-скрипты, часть 6: функции и разработка библиотек
Bash-скрипты, часть 7: sed и обработка текстов
Bash-скрипты, часть 8: язык обработки данных awk
Bash-скрипты, часть 9: регулярные выражения
Bash-скрипты, часть 10: практические примеры
Bash-скрипты, часть 11: expect и автоматизация интерактивных утилит

Сегодня поговорим о bash-скриптах. Это — сценарии командной строки, написанные для оболочки bash. Существуют и другие оболочки, например — zsh, tcsh, ksh, но мы сосредоточимся на bash. Этот материал предназначен для всех желающих, единственное условие — умение работать в командной строке Linux.

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

Андрей Акиньшин (@DreamWalker) — разработчик Rider в JetBrains, мейнтейнер проекта BenchmarkDotNet (библиотека для написания .NET-бенчмарков, поддержанная .NET Foundation), .NET MVP, кандидат физико-математических наук, серебряный призёр ACM ICPC.

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


Андрей Акиньшин — спикер многих конференций. Вот, например, одно из последних выступлений — «Поговорим про арифметику».

На конференции HighLoad++ 2016 Олег Облеухов рассказал о не требующей при росте нагрузки вмешательства администратора архитектуре, которую он спланировал и внедрил в компании InnoGames.

Всем привет. Буквально пару слов обо мне. Меня зовут Олег, до этого я работал в компании «Яндекс», жил в замечательном городе Санкт-Петербурге. Сейчас я переехал в Германию и работаю в InnoGames. Компания занимается разработкой онлайн-игр. На счету 150 миллионов пользователей — достаточно большая компания, ну поменьше, чем «Яндекс», конечно. И сегодня мы поговорим с вами о том, как сделать высоконагруженный сервис без данных о нагрузке, не зная её количество.

Прежде чем мы начнем. Теперь вы все знаете обо мне, я хотел бы узнать немножко об аудитории. Поднимите руку те, кто использует Docker на продакшне? Ну треть зала примерно, хорошо. А теперь из тех, кто поднял руку, поднимите те, кто доволен использованием Docker на продакшне? Значительно меньше. А теперь ещё более сложный вопрос. Те, кто доволен использованием Docker на продакшне, поднимите руку те, кто сисадмин или инженер, или еще кто-то не-разработчик. Я вижу троих. Окей.

На самом деле мы не будем сегодня разговаривать о Docker. Но мы будем разговаривать о CRM. Я вам расскажу, что это такое, зачем нам нужна эта система.

Каждый, кто пользуется командной строкой Linux, встречался со списками полезных советов. Каждый знает, что повседневные дела вполне можно выполнять эффективнее, да только вот одно лишь это знание, не подкреплённое практикой, никому не приносит пользы.

Как выглядят типичные трудовые будни системного администратора, который сидит на Linux? Если абстрагироваться от всего, кроме набираемых на клавиатуре команд, то окажется, что команды эти постоянно повторяются. Всё выходит на уровень автоматизма. И, если даже в работе есть что улучшать, привычка противится новому. Как результат, немало времени уходит на то, чтобы делать так, как привычнее, а не так, как быстрее, и, после небольшого периода привыкания – удобнее. Помнить об этом, сознательно вводить в собственную практику новые полезные мелочи – значит профессионально расти и развиваться, значит – экономить время, которое можно много на что потратить.

Перед вами – небольшой список полезных приёмов работы с командной строкой Linux. С некоторыми из них вы, возможно, уже знакомы, но успели их позабыть. А кое-что вполне может оказаться приятной находкой даже для знатоков. Хочется надеяться, что некоторые из них будут вам полезны и превратятся из «списка» в живые команды, которыми вы будете пользоваться каждый день.

Сегодня мы рассуждаем о тестировании производительности облачных сервисов и систем виртуализации, а также делаем полезные выводы. Но прежде чем говорить о benchmarking’е, давайте задумаемся, как же правильно проводить тесты в виртуальной среде? На самом деле, в этом вопросе есть и свои хитрости, и свои, уже проверенные методы.

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

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

Книга специально предназначена для обучения начинающих сотрудников работе с Linux. Основные достоинства книги:

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

Евгений Потапов ( eapotapov )

Доклад будет про то, что делать с проектом после того, как мы его запустили. Вы спланировали архитектуру проекта, вы продумали, как у него будет работать инфраструктура, продумали, как будете балансировать нагрузку, наконец, его запустили. Что делать дальше? Как поддерживать, как сделать так, чтобы проект продолжал работать, и как сделать так, чтобы ничего, в конце концов, не упало?

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

К вашему сведению! В этой статье мы рассматриваем само явление docker-контейнеров, а не составляем список микросервисов, которые гнездятся внутри. Этим мы займемся в следующей серии, во имя справедливости!

UPDATE: пришлось заменить «докер» на «docker», иначе статья не ищется. Заранее прошу прощения за все «docker'ы» в тексте. Селяви.

Что мы имеем сегодня

• Зоопарк дубовых VPS-хостингов.
• Дорогие IaaS и PaaS с гарантированным vendor lock in.
• Уникальные сервера-снежинки.
• Ворох устаревших зависимостей на неподдерживаемой операционке.
• Скрытые связи частей приложения.
• Незаменимый админ полубог на скейтборде.
• Радуга окружений: development, testing, integration, staging, production.
• Генерация конфигов для системы управления конфигами.
• Feature flagging.
  

Содержание

• Вопросы и ответы
  
• Введение
  
  • Пре-реквизиты
    
  • Настройка компьютера
    
  
  
• 1.0 Играем с Busybox
  
  • 1.1 Docker Run
    
  • 1.2 Терминология
    
  
  
• 2.0 Веб-приложения и Докер
  
  • 2.1 Статические сайты
    
  • 2.2 Образы
    
  • 2.3 Наш первый образ
    
  • 2.4 Dockerfile
    
  • 2.5 Docker на AWS
    
  
  
• 3.0 Многоконтейнерные окружения
  
  • 3.1 SF Food Trucks
    
  • 3.2 Сети Docker
    
  • 3.3 Docker Compose
    
  • 3.4 AWS Elastic Container Service
    
  
  
• 4.0 Заключение
  
  • 4.1 Следующие шаги
    
  • 4.2 Фидбек автору
    

Вопросы и ответы

Что такое Докер?

Определение Докера в Википедии звучит так:

программное обеспечение для автоматизации развёртывания и управления приложениями в среде виртуализации на уровне операционной системы; позволяет «упаковать» приложение со всем его окружением и зависимостями в контейнер, а также предоставляет среду по управлению контейнерами.

Ого! Как много информации.

Всех с наступившим новым годом! Продолжаем разговор о сетях и сегодня затронем такую важную тему в мире коммутации, как VLAN. Посмотрим, что он из себя представляет и как с ним работать. А также разберем работающие с ним протоколы VTP и DTP.

Привет Хабр! Продолжаю свою статью об управление временем. В предыдущей заметке я описал свой подход по работе с ПО Wunderlist для IT. Для меня Wunderlist служит как менеджер задач. Но, как и многим it-специалистам требуется сохранять входящую информацию, личные заметки, мануалы и.т.д. Для этого я использую Evernote.

Я знаю, что большинство используют свои блоги или просто документы. Здесь я не кому не хочу навязывать, рекламировать продукт. Так же, как и в предыдущей заметке, хочу поделиться своим примером использования Evernote для IT в связке с Wunderlist.

Информация пригодиться тем, кто хочет структурировано хранить информацию, не тратить на поиски много времени, а также держать всё под контролем (личную жизнь, хобби, работу).

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