All streams
Search
Write a publication
Pull to refresh
176
0
Пацев Антон @chemtech

DevOps-инженер

Send message

Автоматизация HotFix в Maven проектах с использованием TeamCity

Reading time5 min
Views2.6K

Я из компании Luxoft.
В этом посте будет описана настройка автоматизации HotFix в Maven проектах с использованием Teamcity.


Чтобы сделать HotFix обычно делается много ручных действий:


  1. Создать бранч для релиза, на который вы хотите выкатывать HotFix
  2. Исправить ошибку в релизе
  3. Измененить bugfix версию в релизном бранче
  4. Выкатить тег bugfix версии

Пункты 1,3,4 можно автоматизировать.

Читать дальше →

Установка распределённого отказоустойчивого хранилища объектов LeoFS, совместимого с клиентами, использующими S3, NFS

Reading time11 min
Views6.8K

Я из компании Luxoft.
Согласно Opennet: LeoFS — распределённое отказоустойчивое хранилище объектов LeoFS, совместимое с клиентами, использующими API Amazon S3 и REST-API, а также поддерживающего режим работы в роли NFS-сервера. Имеются оптимизации для хранение как мелких, так и очень больших объектов, присутствует встроенный механизм кэширования, возможна репликация хранилищ между дата-центрами. Среди целей проекта отмечается достижение надёжности 99.9999999% за счёт избыточного реплицирования дубликатов и исключения единой точки отказа. Код проекта написан на языке Erlang.


LeoFS состоит из трёх компонентов:


  • LeoFS Storage — обслуживает операции добавления, извлечения и удаления объектов и метаданных, отвечает за выполнение репликации, восстановления и формирования очереди запросов клиентов.
  • LeoFS Gateway — обслуживает HTTP-запросы и перенаправляет ответы клиентам с использованием REST-API или S3-API, обеспечивает кэширование наиболее востребованных данных в памяти и на диске.
  • LeoFS Manager — отслеживает работу узлов LeoFS Gateway и LeoFS Storage, ведёт мониторинг состояния узлов и проверяет контрольные суммы. Гарантирует целостность данных и высокую доступность хранилища.

В этом посте установим Leofs c помощью ansible-playbook, протестируем S3, NFS.

Читать дальше →

Тестирование android приложений с использованием selenoid. Поиск location в мобильном приложении с помощью Appium

Reading time5 min
Views14K

Я из компании Luxoft.
Предисловие из поста:


Selenoid — это программа, которая позволяет управлять браузерами и Android-эмуляторами с помощью специальных драйверов. Умеет запускать каждый из них изолированно в Docker-контейнере.


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


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


В этом посте будет запуск простых тестов в Android-эмуляторе.

Собираем логи из Nginx с помощью nginx-clickhouse, отправляем в Clickhouse и отображаем в Grafana

Reading time18 min
Views18K

Я из компании Luxoft. В этой статье будет рассматриваться проект nginx-clickhouse, который будет читать логи nginx, отправлять их в clickhouse. Для просмотра аналитики по логам есть дашборд для Grafana.

Читать дальше →

Nginx VTS Stats, Mockify — mock API, сравнение Wiremock и Mockify

Reading time4 min
Views7.4K

В этом посте я хотел сделать демо Nginx VTS + Prometheus + Grafana. Для демо необходимо было чтобы upstream могли выдавать разные http коды. Это могли сделать следующие проекты: Mockify, написанный на Golang, и WireMock, написанный на Java.


Небольшое оглавление


  • установка и настройка Nginx VTS + Prometheus + Grafana;
  • Mockify — легкое, конфигурируемое эмулирование API, написанное на Golang;
  • Сравнение использования CPU для Mockify, написанный на Golang, и WireMock, написанный на Java.
Читать дальше →

Собираем в rpm WireMock — утилиту для создания заглушек над веб-сервисами в Fedora COPR аналоге PPA в Ubuntu

Reading time3 min
Views7.9K

WireMock — утилита, библиотека на java для создания заглушек над веб-сервисами. Он создает HTTP-сервер, к которому мы могли бы подключиться, как к реальному веб-сервису.


Fedora COPR — это бесплатный хостинг для размещения пользовательских репозиториев (аналог AUR в Arch Linux или PPA в Ubuntu). Из особенностей встроенная возможность собирать rpm пакеты указав имя PIP и RubyGems.


В этом посте напишу как собирать rpm из вашего репозитория по коммиту в Fedora COPR.

Читать дальше →

Типовое внедрение мониторинга. Николай Сивко

Reading time12 min
Views4.7K

Расшифровка доклада "Типовое внедрение мониторинга" Николая Сивко.


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


Установка и настройка Nexus Sonatype используя подход infrastructure as code

Reading time18 min
Views132K

Sonatype Nexus – платформа, с помощью которой разработчики могут проксировать, хранить и управлять зависимостями Java (Maven), образами Docker, Python, Ruby, NPM, Bower, RPM-пакетами, gitlfs, Apt, Go, Nuget, а также распространять свое программное обеспечение.


Зачем нужен Sonatype Nexus?


  • Для хранения приватных артефактов;
  • Для кеширования артефактов, которые скачиваются из интернета;
Читать дальше →

Введение в skydive.network

Reading time5 min
Views6.9K

Введение в Skydive


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


Скриншот обьектов (поды, интерфейсы) в kubernetes

«Автоматизация инфраструктуры. Зачем мы это делаем?» (Денис Яковлев)

Reading time11 min
Views3.7K

Предлагаю ознакомиться с расшифровкой доклада Дениса Яковлева "Автоматизация инфраструктуры. Зачем мы это делаем?"


Сам доклад 2016 года. Доклад специально расшифровал для тех, которые создают виртуальные машины руками.


Доклад о том, как мы в компании 2ГИС автоматизировали работу с инфраструктурой.


«Нужно бежать со всех ног, чтобы только оставаться на месте, а чтобы куда-то попасть, надо бежать как минимум вдвое быстрее» (Алиса в стране чудес).


Что эта фраза означает для нас? В условиях жесткой конкуренции, компании должны стремиться доставлять свои продукты до пользователей максимально быстро. Уменьшение параметра time to market — задача многоуровневая. Чтобы ее решить надо менять как процессы разработки, так и инструменты. Важной основой всего процесса разработки является инфраструктура. Чем больше инфраструктура, тем больше с ней проблем, use case'ов и т.д. Если все операции с ней не автоматизированы, то число проблем увеличивается. Одной из них является время, которое разработчик тратит на инфраструктурные вопросы вместо того, чтобы писать бизнес логику.


Поговорим о том:


  • Какие проблемы с инфраструктурой стояли перед командами;
  • Как от этого страдали процессы разработки и тестирования;
  • Как мы внедрили OpenStack;
  • Какие у нас есть сценарии использования OpenStack;
  • Как автоматизация получила дополнительный толчок в развитии и начали появляться новые внутренние продукты;
  • Какие аспекты у нас остались не автоматизированы.

Миграция с Nginx на Envoy Proxy

Reading time10 min
Views39K

Привет, Хабр! Предлагаю вашему вниманию перевод поста: Миграция с Nginx на Envoy Proxy.


Envoy — это высокопроизводительный распределенный прокси-сервер (написанный на C++), предназначенный для отдельных сервисов и приложений, также это коммуникационная шина и «universal data plane», разработанный для больших микросервисных архитектур «service mesh». При его создании были учтены решения проблем, которые возникали при разработке таких серверов, как NGINX, HAProxy, аппаратных балансировщиков нагрузки и облачных балансировщиков нагрузки. Envoy работает вместе с каждым приложением и абстрагирует сеть, предоставляя общие функции независимо от платформы. Когда весь служебный трафик в инфраструктуре проходит через сетку Envoy, становится легко визуализировать проблемные области с помощью согласованной наблюдаемости, настройки общей производительности и добавления основных функций в определённом месте.


Возможности


  • Архитектура вне процесса: envoy — это автономный, высокопроизводительный сервер занимающий небольшой объем оперативной памяти. Он работает совместно с любым языком приложения или фреймворком.
  • Поддержка http/2 и grpc: envoy имеет первоклассную поддержку http/2 и grpc для входящих и исходящих соединений. Это прозрачный прокси от http/1.1 до http/2.
  • Расширенная балансировка нагрузки: envoy поддерживает расширенные функции балансировки нагрузки, включая автоматические повторные попытки, разрыв цепи, глобальное ограничение скорости, затенение запросов, локальную балансировку нагрузки зоны и т. д.
  • API для управления конфигурацией: envoy предоставляет надежный API для динамического управления своей конфигурацией.
  • Наблюдаемость: глубокая наблюдаемость трафика L7, встроенная поддержка распределенной трассировки и наблюдаемость mongodb, dynamodb и многих других приложений.
Читать дальше →

Линтеры в Go. Как их готовить. Денис Исаев

Reading time16 min
Views48K

Предлагаю ознакомиться с расшифровкой доклада Дениса Исаева jirfag "Линтеры в Go. Как их готовить."


В go 50+ линтеров: в чем их профит и как эффективно встроить их в процесс разработки? Доклад будет полезен как тем, кто еще не использует линтеры, так и тем, кто уже применяет их: я раскрою малоизвестные трюки и практики работы с линтерами.



Кому интересно, прошу под кат.

Процесс разработки и тестирования с Docker и Gitlab CI

Reading time14 min
Views46K

Предлагаю ознакомиться с расшифровкой доклада Александра Сигачева из Inventos "Процесс разработки и тестирования с Docker + Gitlab CI"


Те, кто только начинает внедрять процесс разработки и тестирования на базе Docker + Gitlab CI часто спрашивают базовые вопросы. С чего начать? Как организовать? Как тестировать?


Этот доклад хорош тем, что структурировано рассказывает о процессе разработки и тестировании с использованием Docker и Gitlab CI. Сам доклад 2017 года. Думаю что из этого доклада можно почерпнуть основы, методологию, идею, опыт использования.



Кому интересно, прошу под кат.

Пишем высокопроизводительный http клиент на примере fasthttp. Александр Валялкин (VertaMedia)

Reading time15 min
Views36K

Библиотека Fasthttp — ускоренная альтернатива net/http из стандартных пакетов Golang.
Как она устроена? Почему она такая быстрая?


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



Кому интересно, добро пожаловать под кат.

Долгосрочное хранение метрик Prometheus (Алексей Палажченко, Percona)

Reading time21 min
Views32K

За короткое время Prometheus стал одним из самых популярных средств для мониторинга. Благодаря, в том числе, и высокой скорости своей работы. Его локальное хранилище отлично подходит для краткосрочного хранения метрик и работы с ними. Иногда хочется хранить метрики распределённо месяцы и годы, автоматически разрежая старые данные, но не меняя интерфейса работы с ними.


Как раз об этом расшифровка доклада Алексей Палажченко на RootConf 2018. В докладе: Prometheus, Local Storage TSDB, Remote Storage Prometheus, PromQL, TSDB, Сlickhouse, PromHouse, немного InfluxDB.



Кому интересно, прошу под кат.

Инфраструктура как код, выигрываем на масштабе (Кирилл Ветчинкин, TYME)

Reading time15 min
Views23K

Модель «Инфраструктура как код (IaC)», которую иногда называют «программируемой инфраструктурой», — это модель, по которой процесс настройки инфраструктуры аналогичен процессу программирования ПО. По сути, она положила начало устранению границ между написанием приложений и созданием сред для этих приложений. Приложения могут содержать скрипты, которые создают свои собственные виртуальные машины и управляют ими. Это основа облачных вычислений и неотъемлемая часть DevOps.


Инфраструктура как код позволяет управлять виртуальными машинами на программном уровне. Это исключает необходимость ручной настройки и обновлений для отдельных компонентов оборудования. Инфраструктура становится чрезвычайно "эластичной", то есть воспроизводимой и масштабируемой. Одни оператор может выполнять развертывание и управление как одной, так и 1000 машинами, используя один и тот же набор кода. Среди гарантированных преимуществ инфраструктуры как кода — скорость, экономичность и уменьшение риска.


Как раз об этом расшифровка доклада Кирилла Ветчинкина на DevOpsDays Moscow 2018. В докладе: переиспользование модулей Ansible, хранение в Git, ревью, пересборка, финансовые выгоды, горизонтальное масштабирование в 1 клик.



Кому интересно, прошу под кат.

Изменение глобальных настроек на локальных серверах команд в инфраструктуре используя Gitlab CI и Ansible [Концепт]

Reading time5 min
Views5K


В этой статье описывается возможность/идея/концепт изменения глобальных настроек на локальных серверах команд в большой инфраструктуре используя Gitlab CI и Ansible.


Допустим у вас имеются 20 команд разработчиков и 1 команда админов/DevOps. Как менять на всех серверах пароли админов? Как добавить корневой сертификат Предприятия на все сервера? И т.д.

Читать дальше →

Установка kubernetes через kubespray (local-storage, установка Elasticsearch + Fluentd + Kibana, prometheus)

Reading time4 min
Views27K

Как поднять High-Availability Kubernetes кластер и не взорвать мозг? Использовать Kubespray, конечно же.


Kubespray — это набор Ansible ролей для установки и конфигурации системы оркестрации контейнерами Kubernetes.


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


Осторожно, под катом 4 скриншота elasticsearch и 9 скриншотов prometheus!

Читать дальше →

Руководство по виртуализации PCI DSS. Часть 3

Reading time14 min
Views5.2K
Стандарт: Стандарт безопасности данных PCI (PCI DSS)
Версия: 2.0
Дата: Июнь 2011
Автор: Специальная группа по Виртуализации Совет Стандартов Безопасности PCI
Дополнительная информация: Руководство по виртуализации PCI DSS

Руководство по виртуализации PCI DSS. Часть 1
Руководство по виртуализации PCI DSS. Часть 2

4 Рекомендации


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

4.1 Общие рекомендации

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

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

Руководство по виртуализации PCI DSS. Часть 2

Reading time8 min
Views5.9K
Стандарт: Стандарт безопасности данных PCI (PCI DSS)
Версия: 2.0
Дата: Июнь 2011
Автор: Специальная группа по Виртуализации Совет Стандартов Безопасности PCI
Дополнительная информация: Руководство по виртуализации PCI DSS

Руководство по виртуализации PCI DSS. Часть 1
Руководство по виртуализации PCI DSS. Часть 3

3 Риски виртуализированных сред


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

Information

Rating
Does not participate
Location
Омск, Омская обл., Россия
Works in
Date of birth
Registered
Activity

Specialization

DevOps
Senior