Пролог

Тех, кто работал с Kubernetes, вряд ли удивит ситуация, когда внезапно пришла идея по автоматизации, унификации, преобразованию чего-либо в кластере, но так, чтобы не волноваться за конечный результат. Когда возникает потребность в какой-то песочнице, чтобы провести тестирование, проверить гипотезу «на коленке», не используя рабочий Kubernetes-кластер.

В таких случаях приходят на помощь «мини-кластеры». Их можно запустить на рабочем ПК, «поиграться» с примитивами, построить новую структуру, а после завершения эксперимента — безвозвратно удалить (ведь это уже отработанный материал!).

Отвечая на эту потребность, разработчики со всего мира пришли со своими решениями для быстрого запуска облегчённого варианта Kubernetes. Все они по-разному организованы и, конечно, обладают разными возможностями. Чем пользоваться, зависит от нужд и предпочтений. Чтобы получше разобраться в них или вообще понять, с чего стоит начать, предлагаем результаты нашего беглого знакомства с некоторыми популярными решениями. Благо, все они достаточно хорошо документированы (как на сайтах, так и в CLI), что существенно ускоряет первое погружение и взаимодействие с ними. В конце статьи будет сводная таблица с основными особенностями решений.

Соберем пазл Ops’ов.

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

Раньше, IT отделы представляли собой единые команды, но теперь популярна идея организации команд более эффективно для удовлетворения потребностей компании. Основываясь на этих идеях,  IT группы разделяются по специализациям отделов с четкими ролями и требуемыми результатами, продолжая совместную работу. Часть из популярных идей включают в себя  TechOps, DevOps, и NoOps.

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

Разберемся в этих идеях.

TechOps

Широкое и зачастую плохо определяемое назначение TechOps специалистов может дать впечатление, что они занимаются вообще всем, что связано с IT. Действительно, TechOps-задачи сильно разнятся от организации к организации, но все они попадают в категорию по предоставлению и обслуживанию существующей технологической инфраструктуры. Это включает такие вещи как сетевая поддержка, управление базами данных, обеспечение и контроль безопасности, аварийное восстановление, оптимизация сети, установка и обновление программного обеспечения и другие задачи поддержки. 

Всем привет. Я qa automation engineer уже 14 лет и 9 из них мне так или иначе приходилось работать с автоматизацией веб-приложении (и не только). Я писала свои автотесты на C#, Java, и Js. Сейчас я хотела бы поделиться опытом, как я выбираю фреймворк для тестирования веб приложения. Думаю кому-то мой текст может быть полезен. 

Первое, с чего следует начинать создания своего фреймворка, - это с выбора движка взаимодействия с браузером. Именно движок в дальнейшем станет краеугольным камнем ваших тестов. Именно выбор движка является фундаментом дома, который вы строите (и потом этот фундамент никак не переделать сторонними библиотеками).

Одна из новых возможностей, появившихся в Python 3.7 — классы данных (Data classes). Они призваны автоматизировать генерацию кода классов, которые используются для хранения данных. Не смотря на то, что они используют другие механизмы работы, их можно сравнить с "изменяемыми именованными кортежами со значениями по умолчанию".

• PEP 557 — Data classes
• Официальная документация

Введение

Все приведенные примеры требуют для своей работы Python 3.7 или выше

Большинству python-разработчикам приходится регулярно писать такие классы:

class RegularBook:
    def __init__(self, title, author):
        self.title = title
        self.author = author

Уже на этом примере видна избыточность. Идентификаторы title и author используются несколько раз. Реальный класс же будет ещё содержать переопределенные методы __eq__ и __repr__.

Модуль dataclasses содержит декоратор @dataclass. С его использованием аналогичный код будет выглядеть так:

from dataclasses import dataclass

@dataclass
class Book:
    title: str
    author: str

1. Введение
2. Заблуждения о this
3. Как определить значение this

Введение

Листая страницы Хабра, поймал себя на мысли, что я воспринимаю Хабр  как новостную ленту в социальной сети. То есть как нечто, что прямого отношения лично ко мне не имеет и касается меня очень  косвенным путем. Нечто полуразвлекательное-полупознавательное.

Ну, судите сами. Вот примерный список тем, которые превалируют на Хабре.

1. Что там новенького  у Илона Петровича Маска.

2. Как с помощью Arduino, говна и палок сделать годный фаллоимитатор радиоприемник.

3. Как я ушел с прошлой работы, и как мне было там плохо.

4. Как я нашел свою текущую работу, и какая она крутая.

5. Как живется специалисту X в стране Y.

6. Какой путь нужно проделать фельдшеру из Ангарска, чтобы стать тестировщиком мобильных приложений в Ирландии.

7. Обсуждение новомодной платформы для веб-разработки, которая через 3 года станет старомодной.

8. Промываем косточки крупным компаниям.

9. Исторические экскурсы в IT/технологии/медицину.

10.   Реклама компаний.

11.   Мнения обо всем отвлеченном на свете.

12.   И т.д.

Все эти темы и все статьи – неплохие, интересные. Но я хотел бы другого.

Мы делили апельсин, много нас, а он один

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

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

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

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

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

Корректирующие (или помехоустойчивые) коды — это коды, которые могут обнаружить и, если повезёт, исправить ошибки, возникшие при передаче данных. Даже если вы ничего не слышали о них, то наверняка встречали аббревиатуру CRC в списке файлов в ZIP-архиве или даже надпись ECC на планке памяти. А кто-то, может быть, задумывался, как так получается, что если поцарапать DVD-диск, то данные всё равно считываются без ошибок. Конечно, если царапина не в сантиметр толщиной и не разрезала диск пополам.

Как нетрудно догадаться, ко всему этому причастны корректирующие коды. Собственно, ECC так и расшифровывается — «error-correcting code», то есть «код, исправляющий ошибки». А CRC — это один из алгоритмов, обнаруживающих ошибки в данных. Исправить он их не может, но часто это и не требуется.

Давайте же разберёмся, что это такое.

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

Внимание! Много текста и мало картинок. Я постарался всё объяснить, но без карандаша и бумаги текст может показаться немного запутанным.

«Мы не проводим никакие массированные атаки. Мы ведем целенаправленную работу по повышению эффективности блокировки пиратского контента», — подчеркнул пресс-секретарь Роскомнадзора в беседе с корреспондентом «Газеты.Ru».

Он уточнил, что ни о каком замедлении трафика для пользователей трекера речи не идет, а блокировка RuTracker проводится в плановом режиме.

Это практическое пособие познакомит вас c Ansible. Вам понадобится виртуальная или реальная машина, которая будет выступать в роли узла для Ansible. Окружение для Vagrant идет в комплекте с этим пособием.

Ansible — это программное решение для удаленного управления конфигурациями. Оно позволяет настраивать удаленные машины. Главное его отличие от других подобных систем в том, что Ansible использует существующую инфраструктуру SSH, в то время как другие (chef, puppet, и пр.) требуют установки специального PKI-окружения.

Пособие покрывает такие темы:

1. Установка Ansible и Vagrant
2. Файл инвенторизации
3. Модули shell, copy, сбор фактов, переменные
4. Запуск на группу хостов
5. Плейбуки
6. Пример: поднимаем кластер, устанавливаем и настраиваем Apache и балансировщик нагрузок HAproxy
7. Обработка ошибок, откат
8. Шаблоны конфигурации
9. Роли

Ansible использует так называемый push mode: конфигурация «проталкивается» (push) с главной машины. Другие CM-системы обычно поступают наоборот – узлы «тянут» (pull) конфигурацию с главной машины.

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