DevOps *

Нет времени и желания изучать километровые файлы WiX, чтобы собрать MSI инсталлер для своего проекта, погружаясь при этом в бездны MSDN? Хотите собирать инсталлер, описывая его простыми и понятными терминами, в несколько строк? Есть клиническая склонность к кроссплатформенности и сборкам под Linux & Docker? Ну тогда вам под кат!

Southbridge проводит живой и онлайн-интенсив по Кубернетес.

Материал рассчитан на тех, кто знает Linux, Docker, Kubernetes, Ansible, Helm и Git.

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

Темы занятий:

Несколько месяцев назад я написал статью о контроллере Kubernetes Nginx Ingress, которая занимает второе место по популярности в этом блоге. Основная ее тема — использование Kubernetes Ingress для локальных развертываний. Впрочем, большинство пользователей использует Kubernetes в облаке AWS и общедоступных облачных сервисах других поставщиков. Однако проблема заключается в том, что для каждого сервиса типа LoadBalancer AWS создает новый балансировщик ELB (Elastic Load Balancer). Это может оказаться слишком дорогим удовольствием. Если взять на вооружение Kubernetes Ingress, потребуется лишь один ELB.

За 10 лет Southbridge создал стандарт работы, который позволяет одному администратору поддерживать 150 серверов, быстро проводить первичную настройку, легко передавать проект между администраторами и группами, сразу видеть, что сделали ночные дежурные, быстро входить в курс дела после отпуска, и, естественно, обеспечить клиенту надежность и безопасность инфраструктуры.

C 22 по 24 октября Southbridge проводит интенсив для системных администраторов, где покажет свои подходы, регламенты, инструменты, инструкции и скрипты.

По сути РедСлёрм — это набор материалов для подготовки нового сотрудника Southbridge.

Осваивать подход к администрированию, основанный на унификации и стандартизации, полезно даже начинающему администратору.

Все, что можно, отрабатываем на практике.

Вам наверняка приходилось восстанавливать кластер Kubernetes после сбоя. Была ли у вас толковая стратегия резервного копирования, не требующая пахать несколько дней? Да, можно делать резервные копии в etcd-кластер, но что если отвалилась только часть кластера или вы используете постоянные тома, вроде AWS EBS?

В таких случаях проще всего использовать утилиту Heptio Ark.

Рано или поздно в любом проекте настает время работать над стабильность/доступностью вашего сервиса. Для каких-то сервисов на начальном этапе важнее скорость разработки фич, в этот момент и команда не сформирована полностью, и технологии выбираются не особо тщательно. Для других сервисов (чаще технологические b2b) для завоевания доверия клиентов необходимость обеспечения высокого uptime возникает с первым публичным релизом. Но допустим, что момент X все-таки настал и вас начало волновать, сколько времени в отчетный период "лежит" ваш сервис. Под катом я предлагаю посмотреть, из чего складывается время простоя, и как эффективнее всего работать над его уменьшением.

var_dump($variable);
die();

console.log(data);

echo json_encode($variable, JSON_UNESCAPED_UNICODE);
exit();

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

Слёрм-2 (25–27 октября) — для тех, кто только осваивает Кубернетес: создаем кластер и запускаем на нем приложение.

МегаСлёрм (29–31 октября) — для тех, кто уже работает с Кубернетес или был на Слёрм-1: создаем production-ready кластер.

Темы Слерм-2 и МегаСлерм включают все темы экзамена на Certified Kubernetes Administrator.

Сайт Слёрма-2
Сайт МегаСлёрма

.base_deploy: &base_deploy
  stage: deploy
  script:
  - PROJECT_NAME="${CI_PROJECT_NAME}-${CI_ENVIRONMENT_SLUG}"
  - helm --namespace ${CI_ENVIRONMENT_SLUG} upgrade -i ${PROJECT_NAME} helm --set "global.env=${CI_ENVIRONMENT_SLUG}";

stages:
  - deploy

Deploy to Test:
  <<: *base_deploy
  environment:
    name: test

Deploy to Production:
  <<: *base_deploy
  environment:
    name: production
  when: manual