Привет!
27 сентября, в четверг, мы снова решили собрать митап QIWI SERVER PARTY.
Если вам интересны DevOps и работа с Kubernetes, то добро пожаловать под кат, там мы собрали темы докладов, с которым будут выступать наши ребята, и видео с предыдущего митапа.
Читать полностью »
Когда приложение было монолитным и вдруг, раз, стало распределённым, в формулу вычисления доступности добавляется ещё одна неизвестная — сетевая. Из-за проблем с вызовами между компонентами, приложения часто валятся и начинают дрыгать ножками. А выяснение причин нестабильной работы распределённого приложения — та ещё задачка. Дополнительную неразбериху в структуру приложения вносит условный kubernetes, который по своему внутреннему усмотрению может произвольно распределять условные поды по условным нодам. Пишу «условный», потому что на месте kubernetes может быть и Swarm и Openshift и прочие и прочие.
Я к тому, что без нормальной визуализации разобраться где температурит, может быть очень непросто. Под катом моё представление о потенциальных возможностях инструментов, которые умеют рисовать карту приложения и подсвечивать места для прикладывания подорожника, а также список этих самых инструментов со скриншотами.
Читать полностью »
Каждый вторник по вечерам собирается клуб анонимных любителей DevOps. Наши задачи намного амбициознее, чем просто поделиться своей проблемой и, возможно, получить совсет. Мы обсуждаем все тренды отрасли, чтобы на конференции и секции по DevOps самим было бы приятно прийти.
С июля мы работаем над DevOpsConf Russia, профессиональной конференцией по интеграции процессов разработки, тестирования и эксплуатации, которая выросла из RootConf и пройдет 1 и 2 октября в Москве, в Инфопространстве.
Сегодня я расскажу вам, как мы это делаем, какие доклады стараемся отбирать, о чем просим докладчиков.
Прим. перев.: Статья написана Javier Salmeron — инженером из хорошо известной в Kubernetes-сообществе компании Bitnami — и была опубликована в блоге CNCF в начале августа. Автор рассказывает о самых основах механизма RBAC (управление доступом на основе ролей), появившегося в Kubernetes полтора года назад. Материал будет особенно полезным для тех, кто знакомится с устройством ключевых компонентов K8s (ссылки на другие подобные статьи см. в конце).
Слайд из презентации, сделанной сотрудником Google по случаю релиза Kubernetes 1.6
Многие опытные пользователи Kubernetes могут вспомнить релиз Kubernetes 1.6, когда авторизация на основе Role-Based Access Control (RBAC) получила статус бета-версии. Так появился альтернативный механизм аутентификации, который дополнил уже существующий, но трудный в управлении и понимании, — Attribute-Based Access Control (ABAC). Все с восторгом приветствовали новую фичу, однако в то же время бесчисленное число пользователей были разочарованы. StackOverflow и GitHub изобиловали сообщениями об ограничениях RBAC, потому что большая часть документации и примеров не учитывали RBAC (но сейчас уже всё в порядке). Эталонным примером стал Helm: простой запуск helm init + helm install больше не работал. Внезапно нам потребовалось добавлять «странные» элементы вроде ServiceAccounts или RoleBindings ещё до того, как разворачивать чарт с WordPress или Redis (подробнее об этом см. в инструкции).Читать полностью »
В данной статье я хочу рассказать как деплоить приложения в разные среды. В этом примере, мы будем деплоить в: «Test» и «Production». Разумеется, вы можете добавить любые среды.
Для деплоя приложений я использую HELM. Он позволяет гибко управлять конфигурациями. В чем вы сможете убедится ниже. Предполагается, что у вас уже есть настроенный runner с helm-ом и вы знаете и умеете работать с HELM-ом.
Пример файла: .gitlab-ci.yml
.base_deploy: &base_deploy
stage: deploy
script:
- PROJECT_NAME="${CI_PROJECT_NAME}-${CI_ENVIRONMENT_SLUG}"
- if [[ -z $(helm ls ${PROJECT_NAME} --deployed -q) ]]; then
helm --namespace ${CI_ENVIRONMENT_SLUG} --name ${PROJECT_NAME} install helm --set "global.env=${CI_ENVIRONMENT_SLUG}";
else
helm upgrade ${PROJECT_NAME} helm --set "global.env=${CI_ENVIRONMENT_SLUG}";
fi
stages:
- deploy
Deploy to Test:
<<: *base_deploy
environment:
name: test
Deploy to Production:
<<: *base_deploy
environment:
name: production
when: manual
Здесь стоит обратить внимание на то, что в зависимости от среды мы передаем переменную: «test» или «production».
Имя проекта мы тоже формируем с учетом имени переменной, для того, чтобы helm понимал, что это разные проекты (helm ls).
Далее, мы передаем эту переменную (среду) в HELM как: «global.env».
Для выше указанного примера helm должен находиться в одноименной папке в вашем репозиторие.
Читать полностью »
28 августа организация CNCF (Cloud Native Computing Foundation), стоящая за Kubernetes, Prometheus и другими Open Source-проектами для современных облачных приложений, объявила о принятии нового продукта в свою «песочницу» — TiKV.
Эта распределённая, транзакционная база данных типа ключ-значение зародилась как дополнение к TiDB — распределённой СУБД, которая предлагает возможности OLTP и OLAP и обеспечивает совместимость с протоколом MySQL… Но давайте обо всём по порядку.Читать полностью »
Всем добра!
Ну вот и подошло время для очередного нашего курса по Девопсу. Наверное, это один из самых стабильных и эталонных курсов, но при этом и самый разнообразный по обучающимся, так как ни одна группа ещё не была похожа на другую: то в одной разработчики почти полностью, то в следующей инженеры, то админы и так далее. А так же это значит, что пришла пора интересных и полезных материалов, а так же онлайн-встреч.
Поехали.
В этой статье собраны рекомендации по запуску production-grade Kubernetes кластера в условиях on-premise дата-центра или периферийных локаций (edge location).
Что значит production-grade?
Если коротко, production-grade означает предвосхищение ошибок и подготовку восстановления с минимальным количеством проблем и отсрочек.
Привет! Сегодня мы делимся с вами простым и понятным руководством по тому, как применять Mobile DevOps на практике. Помимо бумажного руководства, под катом вы также сможете найти видео-записи одноименного мастер-класса, где рассмотрен каждый аспект DevOps применительно к мобильной разработке.
Статья является логическим продолжение нашей недавней публикации об истории пакетного менеджера для Kubernetes — Helm. В этот раз мы снова затронем вопросы устройства и функционирования нынешнего Helm (версия 2.x), а также управляемых им чартов и репозиториев, после чего перейдём к практике: установке Helm в кластер Kubernetes и использованию чартов.Читать полностью »
На DevOps есть по крайней мере два устоявшихся взгляда — со стороны системных администраторов и со стороны разработчиков. Первые обычно хвастаются тем, что используют Chef/Puppet/Ansible/Docker c 200X года, вторые считают, что DevOps либо изжил себя и ведет к NoOps, либо что «я завернул всё в контейнер, а дальше как пойдёт».
Бизнес при этом читает про DevOps в статьях и надеется, что ребята снизу разберутся, что с ним делать. При этом самого DevOps не происходит, бизнес не похож на Google, компания не становится бирюзовой, люди не создают новых подходов для проверки гипотез в мире.
Эта статья — про DevOps как систему. Как он помогает бизнесу, какие компетенции со стороны инженеров должны появиться для DevOps, какие бизнес-задачи можно решать DevOps-методом производства программного обеспечения, а также какие ошибки возможны на пути к DevOps-производству и как их избежать или купировать. Как, в конце концов, инженеру стать Человеком и быть в этом мире творцом, как для этого построить карьерный путь и как начать смотреть на технологии по-человечески.
В основе материала — расшифровка доклада Александра osminog Титова с нашей октябрьской конференции DevOops 2017.
