• Типовые ситуации при непрерывной интеграции

    • Перевод
    • Tutorial

    Вы изучили команды Git но хотите представлять, как непрерывная интеграция (Continuous Integration, CI) происходит в реальности? Или может вы хотите оптимизировать свои ежедневные действия? Этот курс даст вам практические навыки непрерывной интеграции с использованием репозитория на GitHub. Данный курс не задуман как некий визард, который можно просто прокликать, напротив, вы будете совершать те же действия, что люди на самом деле делают на работе, тем же способом, которым они это делают. Я буду объяснять теорию по мере прохождения вами имеющих к ней отношение шагов.


    Что мы будем делать?


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


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


    Шаги непрерывной интеграции


    Вы пройдёте такие стандартные для CI сценарии:


    • Работа над фичей;
    • Применение автотестов для обеспечения качества;
    • Реализация приоритетной задачи;
    • Разрешение конфликта при слиянии ветвей (merge conflict);
    • Возникновение ошибки в продуктивной среде.
    Читать дальше →
  • Закулисье. Как рождаются курсы?

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


      А ещё кофебрейки с единомышленниками, бодрая и драйвовая атмосфера, обмен опытом, самые неожиданные вопросы спикерам. И ответы, и информация, которую не встретишь в мануалах, а только на практике.


      Как думаете, сколько ушло времени, сил и нервов, чтобы оно выглядело именно так?



      Читать дальше →
      • +18
      • 5,1k
      • 1
    • Правильно [c]читаем параллельные планы PostgreSQL

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

        Поэтому внутри каждого отдельного процесса нет никаких традиционных «странных» проблем с параллельным выполнением кода, блокировками, race condition,… А разработка самой СУБД приятна и проста.

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

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


        Со схемами работы некоторых параллельных узлов можно ознакомиться в статье «Parallelism in PostgreSQL» by Ibrar Ahmed, откуда взято и это изображение.
        Правда, читать планы в этом случае становится… нетривиально.
        Читать дальше →
      • Управляем сетевыми подключениями в Linux с помощью консольной утилиты nmcli

        • Перевод
        • Tutorial
        Используйте все возможности инструмента управления сетевыми подключениями NetworkManager в командной строке Linux c помощью утилиты nmcli.



        Утилита nmcli напрямую обращается к API для доступа к функциям NetworkManager.

        Она появилась в 2010 году и для многих стала альтернативным способом настройки сетевых интерфейсов и соединений. Хотя кто-то до сих пор использует ifconfig. Так как nmcli — это инструмент интерфейса командной строки (CLI), предназначенный для использования в окнах терминалов и скриптах, он идеально подходит для системных администраторов, работающих без GUI.
        Читать дальше →
      • Семь архетипов превращения по принципам DevOps

          Вопрос «как внедрить у себя девопс» стоит не первый год, но хороших материалов не так много. Иногда вы становитесь жертвой рекламы не особо умных консультантов, которым нужно продать свое время, неважно как. Иногда это мутные, крайне общие слова о том, как корабли мегакорпораций бороздят просторы вселенной. Возникает вопрос: а нам-то с этого что? Уважаемый автор, можете внятно списочком сформулировать свои идеи?

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



          Джон Уиллис — один из отцов DevOps. За плечами у Джона — десятки лет работы с огромным количеством компаний. В последнее время Джон стал для себя замечать специфические паттерны, которые имеют место быть в работе с каждой из них. Используя эти архетипы, Джон наставляет компании на истинный путь DevOps-трансформации. Подробнее об этих архетипах — в переводе его доклада с конференции DevOops 2018.
          Читать дальше →
          • +27
          • 9,1k
          • 1
        • «Никаких кликов»: интервью с Джессикой Дин о командной строке, автоматизации и DevOps


            Мне нравятся хоткеи, алиасы, shell-скрипты и другие способы повысить свою продуктивность с помощью клавиатуры. Сам я не очень далеко зашёл на этом пути, но меня всегда впечатляют люди, по-настоящему углубившиеся в это, и хочется их расспрашивать.


            Осенью на нашей конференции DevOops выступала Джессика Дин. Она удивительно разносторонний человек в отношении платформ: обожает Linux, постоянно пользуется Mac и при этом работает в Microsoft. И она очень любит автоматизацию, скрипты и отказ от мышки — настолько, что в её дотфайлах уже сотни коммитов.


            В трансляции DevOops мы с Михаилом Дружининым (xomyakus) поспрашивали её и об использовании терминала, и о совмещении миров Windows/Linux/Mac, а поскольку дело было на девопс-конференции, к концу разговор свернул ещё и в сторону Kubernetes. А сейчас, прямо перед новым онлайновым DevOops, мне захотелось перевести это интервью на русский, чтобы оно было и в текстовом формате.

            Читать дальше →
          • Не стоит пользоваться OFFSET и LIMIT в запросах с разбиением на страницы

            • Перевод
            Прошли те дни, когда не надо было беспокоиться об оптимизации производительности баз данных. Время не стоит на месте. Каждый новый бизнесмен из сферы высоких технологий хочет создать очередной Facebook, стремясь при этом собирать все данные, до которых может дотянуться. Эти данные нужны бизнесу для более качественного обучения моделей, которые помогают зарабатывать. В таких условиях программистам необходимо создавать такие API, которые позволяют быстро и надёжно работать с огромными объёмами информации.


            Читать дальше →
          • Fluentd: почему важно настроить выходной буфер


              В наше время невозможно представить проект на базе Kubernetes без стека ELK, с помощью которого сохраняются логи как приложений, так и системных компонентов кластера. В своей практике мы используем стек EFK с Fluentd вместо Logstash.


              Fluentd — это современный универсальный коллектор логов, набирающий всё большую популярность и присоединившийся к Cloud Native Computing Foundation, из-за чего вектор его разработки ориентирован на использование совместно с Kubernetes.


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


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

              Читать дальше →
            • Kubernetes: почему так важно настроить управление ресурсами системы?

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


                Читать дальше →
              • Немного неудобно, но хочу поговорить о буферах

                  Просто статья о буферах. Вы наверняка думаете, что знаете о буферах всё. Возможно, так оно и есть. Но мне кажется, вы всё равно найдёте для себя что-то новое. Просто потому, что тема – неисчерпаемая. О буферах всегда есть что сказать.

                  Это не чушь, и не шутка. Статья действительно о буферах. И она не про буфер обмена. Речь пойдёт о буферах, которые помогают работать лучше.
                  Читать дальше →
                • Современные приложения на OpenShift, часть 2: связанные сборки chained builds

                    Всем привет! С вами второй пост из нашей серии, в которой мы показываем, как развертывать на Red Hat OpenShift современные веб-приложения.



                    В предыдущем посте мы слегка затронули возможности нового builder-образа S2I (source-to-image), который предназначен для сборки и развертывания современных веб-приложений на платформе OpenShift. Тогда нас интересовала тема быстрого развертывание приложения, а сегодня мы рассмотрим, как использовать S2I-образ в качестве «чистого» builder-образа и совмещать его со связанными сборками OpenShift.
                    Читать дальше: Современные приложения на OpenShift, часть 2: связанные сборки chained builds
                  • Ты можешь писать безупречные ТЗ, но какой в этом толк, если разработчик твой плачет?



                    В далекой-далекой галактике трудится сферический product owner. Он бегло пишет заметки на салфетке и молча отдает ее разработчикам. А вскоре получает готовый продукт, который на 100% соответствует его ожиданиям. Даже если продукт этот – сложный кроссплатформенный сервис с блэкджеком и адаптивностью.

                    Возможно ли такое на практике?
                    Читать дальше →
                  • SRE: Анализ производительности. Способ настройки с использованием простого вебсервера на Go

                    • Перевод
                    • Tutorial

                    Анализ производительности и настройка — мощный инструмент проверки соответствия производительности для клиентов.


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


                    Go тут особенно хорошо подходит, поскольку у него есть инструменты профилирования pprof в стандартной библиотеке.


                    Читать дальше →
                  • Минимально жизнеспособный Kubernetes

                    • Перевод
                    Перевод статьи подготовлен в преддверии старта курса «DevOps практики и инструменты».





                    Если вы это читаете, вероятно, вы что-то слышали о Kubernetes (а если нет, то как вы здесь оказались?) Но что же на самом деле представляет собой Kubernetes? Это “Оркестрация контейнеров промышленного уровня”? Или «Cloud-Native Operating System»? Что вообще это значит?

                    Честно говоря, я не уверен на 100%. Но думаю интересно покопаться во внутренностях и посмотреть, что на самом деле происходит в Kubernetes под его многими слоями абстракций. Так что ради интереса, давайте посмотрим, как на самом деле выглядит минимальный “кластер Kubernetes”. (Это будет намного проще, чем Kubernetes The Hard Way.)

                    Я полагаю, что у вас есть базовые знания Kubernetes, Linux и контейнеров. Все, о чем мы здесь будем говорить предназначено только для исследования/изучения, не запускайте ничего из этого в продакшене!
                    Читать дальше →
                    • +10
                    • 4,2k
                    • 2
                  • Eще один бэкап — больше, чем скрипт, проще, чем система

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



                      Добрый день, Habr!
                      Меня зовут Наталья. Я тимлид группы администраторов приложений в НПО «Криста». Мы Ops для группы проектов нашей компании. У нас довольно своеобразная ситуация: мы устанавливаем и сопровождаем наше ПО как на серверах нашей компании, так и на серверах, расположенных у клиентов. При этом бэкапить сервер целиком нет необходимости. Важны лишь «существенные данные»: СУБД и отдельные каталоги файловой системы. Конечно, клиенты имеют (или не имеют) свои регламенты резервного копирования и часто предоставляют некое внешнее хранилище для складывания туда резервных копий. В этом случае после создания бэкапа мы обеспечиваем отправку во внешнее хранилище.

                      Какое-то время для целей бэкапа мы обходились bash-скриптом, но по мере разрастания вариантов настроек пропорционально росла и запутанность этого скрипта, и в один прекрасный момент мы пришли к необходимости его «разрушить до основанья, а затем....».
                      а как же готовые решения?
                    • Сбор метрик SpringBoot-приложения в AWS CloudWatch

                        Привет! Меня зовут Артем Арешко, я являюсь ведущим Java разработчиком в компании Luxoft на Fin-Tech проекте. Сегодня поговорим о метриках, Spring Boot и облаках Amazon.

                        В качестве вступления...


                        Промышленная эксплуатация требует знаний о том, как живет приложение. Этот тезис следует взять за аксиому. Таковыми знаниями являются метрики, производимые приложением. Метрики могут быть как чисто техническими (например, количество потребляемой ОЗУ) так и бизнесовыми (например, совершенные заказы).

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

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

                          В последние два месяца лета в управлении хранилищ данных (Data Warehouse, DWH) Тинькофф Банка появилась новая тема для кухонных споров.

                          Всё это время мы проводили масштабное тестирование нескольких in-memory СУБД. Любой разговор с администраторами DWH в это время можно было начать с фразы «Ну как, кто лидирует?», и не прогадать. В ответ люди получали длинную и очень эмоциональную тираду о сложностях тестирования, премудростях общения с доселе неизвестными вендорами и недостатках отдельных испытуемых.

                          Подробности, результаты и некое подобие выводов из тестирования — под катом.
                          Читать дальше →
                        • Запускаем полноценный кластер на Kubernetes с нуля на Ubuntu 16.04

                          Уже довольно много написано статей, по установке и запуску Kubernetes, однако, не всё так гладко (я потратил несколько суток на запуск своего кластера).

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

                          Что нужно знать


                          Серверы:
                          Кластер подразумевает, что у Вас более одного физического сервера, между которыми и будут распределятся ресурсы. Серверы называются нодами (nodes).

                          Диски:
                          Обычные харды в k8s не поддерживаются. Работа с дисками происходит по средствам распределенных файловых хранилищ. Это необходимо для того, чтобы k8s мог «перемещать» контейнеры docker на другие ноды в случае необходимости, без потери данных (файлов).

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

                          Минимальное разумное количество серверов для Ceph — 3 (можно построить и на одном, но в этом мало смысла из-за высокой вероятности потерять данные).

                          Сеть:
                          Нам понадобится Flannel — он позволяет организовать программно определяемую сеть (Software Defined Network, SDN). Именно SDN позволяет всем нашим контейнерам общаться с друг другом внутри кластера (установка Flannel производится вместе с k8s и описана ниже).

                          Подготовка серверов


                          В нашем примере мы используем 3 физических сервера. Установите Ubuntu 16.04 на все сервера. Не создавайте swap партиции (требование k8s).

                          Предусмотрите в каждом сервере как минимум один диск (или партицию) для Ceph.

                          Не включайте поддержку SELinux (в Ubuntu 16.04 он выключен по-умолчанию).

                          Мы назвали сервера так: kub01 kub02 kub03. Партиция sda2 на каждом сервере создана для Ceph (форматировать не обязательно).
                          Читать дальше →
                        • Иллюстрированное руководство по устройству сети в Kubernetes. Части 1 и 2

                          • Перевод
                          Прим. перев.: Автор статьи — Amanpreet Singh — называет себя «всё ещё начинающим в мире сетей», однако именно это и побудило его разобраться в их базовом устройстве в Kubernetes (который он использует в production), а затем — поделиться с сообществом очень доступным материалом с наглядными иллюстрациями. В оригинале он разбит на две части, однако в этом переводе мы объединили их в одну статью.



                          Вот вы запустили множество сервисов в кластере Kubernetes и пожинаете плоды… или хотя бы собираетесь это сделать. Однако, даже несмотря на существование ряда утилит для настройки кластера и управления им, вам всё же интересно, как всё работает «под капотом». Куда смотреть, если что-то сломается? По себе знаю, что это важно.
                          Читать дальше →
                          • +38
                          • 27,3k
                          • 2
                        • Масштабирование CI/CD монорепозитория

                          Lerna


                          Дано


                          1. Монорепозиторий на базе Lerna и Yarn workspaces.
                          2. Десяток приложений, и десятки общих пакетов на TypeScript, Angular, NodeJS.
                          3. Высокое покрытие тестами самых разных мастей (модульные, интеграционные, e2e).
                          4. и Atlassian Bamboo CI/CD.

                          Задача


                          Ускорить имеющиеся пайплайны в 2 раза (до, хотя бы, получаса). Попутно повысив стабильность до 90%.


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

                          Читать дальше →
                          • +11
                          • 2,7k
                          • 6