DevOps *

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

• Коллеги из Hystax на примере клиентского кейса покажут, какой нелёгкой бывает миграция виртуальных машин между облаками и гипервизорами;
• Mail.Ru Cloud Solutions поделятся опытом работы с OpenStack и Linux Storage Stack: о чём часто забывают, планируя хранилище?
• Canonical продолжат рассказывать про свой подход к моделированию инфраструктуры. В этот раз вы узнаете, каким образом MAAS и Juju позволяют в автоматизации упростить работу с серверами с большим количеством сетевых интерфейсов и L3-ориентированной сетевой топологией.

Было бы круто, если бы развертывание в формате копи-пейст осталось в прошлом, но, увы, дела обстоят иначе. Бывает, разработчикам предпочтительней именно такой метод поставки. Хоть сейчас пиши статью о том, почему это не есть гуд, но вы и без меня все знаете. С тенденцией к бессерверной (serverless) архитектуре пайплайны CI/CD играют важную роль в поставке приложений. Я еще писал о них в статье "3 лучших совета для вашего следующего бессерверного проекта".

Темой CI и CD я интересуюсь давненько, а впервые столкнулся с ней несколько лет назад — благодаря TeamCity. В настоящее время TeamCity по-прежнему используется для большинства наших пайплайнов CI/CD. Работает TeamCity прекрасно, ничего против не имею, но я всегда стремлюсь улучшить работу. Например, было бы хорошо собирать пайплайны в виде кода — это одно из направлений, в которых TeamCity не так хорош.

Инструменты интеграции и поставки на AWS я изучил какое-то время назад, и, хотя мы используем CodeDeploy для другого проекта, который работает на EC2, бессерверный проект я с ними еще не развертывал. Ознакомившись с инструментами повторно, я обратил внимание вот на что: теперь есть встроенная функция интеграции для развертывания CloudFormation и Lambda, предположительно, на основе SAM AWS; мы используем serverless framework, — она генерирует шаблоны CloudFormation, но с инструментами AWS она “из коробки” не работает.

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

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

Выпущенный в ноябре 2018 года AresDB представляет собой инструмент анализа в реальном времени с открытым исходным кодом. Он использует нетрадиционный источник питания, графические процессоры (GPU), что позволяет увеличивать масштаб анализа. Технология GPU, перспективный инструмент анализа в реальном времени, за последние годы значительно продвинулась, что делает ее идеальной для параллельных вычисления в реальном времени и обработки данных.

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

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

https://github.com/zfsonlinux/zfs/wiki/Ubuntu-18.04-Root-on-ZFS

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

Для начала подготовим виртуальную машину, для этого напишем небольшой скрипт, который разворачивает и автоматизирует некоторые рутинные операции, скрипт использует Azure Cli:

#!/bin/bash
echo "AZURE VM Create"
echo "Azure Account:"
echo "Azure name:"
read AZ_NAME
read -sp "Azure password: " AZ_PASS && echo && az login -u $AZ_NAME -p $AZ_PASS
echo "Name Group  VM"
read GROUP_NAME
az group create --name $GROUP_NAME --location eastus
echo "VM name"
read VM
echo "Admin user name"
read ADMIN
az vm create --resource-group $GROUP_NAME --name $VM --image UbuntuLTS --admin-username $ADMIN --generate-ssh-keys --custom-data cloud-init.txt
az vm open-port --resource-group $GROUP_NAME --name $VM --port 8080 --priority 1001
az vm open-port --resource-group $GROUP_NAME --name $VM --port 8081 --priority 1002
az vm open-port --resource-group $GROUP_NAME --name $VM --port 9090 --priority 1003
az vm open-port --resource-group $GROUP_NAME --name $VM --port 9093 --priority 1004
az vm open-port --resource-group $GROUP_NAME --name $VM --port 9100 --priority 1005
az vm open-port --resource-group $GROUP_NAME --name $VM --port 3000 --priority 1006
RESULT=$(az vm show --resource-group $GROUP_NAME --name $VM -d --query [publicIps] --o tsv)
echo $RESULT
echo "Whait 5 min"
sleep 300
ssh $ADMIN@$RESULT -y << EOF
sudo usermod -aG docker $ADMIN
EOF
sleep 10
echo "Connect to Azure..."

В скрипте мы используем файл cloud-init.txt который автоматически установит Docker и Docker-Compose на виртуальную машину.

#cloud-config
package_upgrade: true
write_files:
  - path: /etc/systemd/system/docker.service.d/docker.conf
    content: |
      [Service]
        ExecStart=
        ExecStart=/usr/bin/dockerd
  - path: /etc/docker/daemon.json
    content: |
      {
        "hosts": ["fd://","tcp://127.0.0.1:2375"]
      }
runcmd:
- apt-get update && apt-get install mc -y
- curl -sSL https://get.docker.com/ | sh
- curl -L "https://github.com/docker/compose/releases/download/1.23.2/docker-compose-$(uname -s)-$(uname -m)" -o /usr/local/bin/docker-compose
- chmod +x /usr/local/bin/docker-compose

Часть 2/3 тут
Часть 3/3 тут

Всем привет! В этой статье я хочу упорядочить информацию и поделиться опытом создания и использования внутреннего кластера Kubernetes.

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

0. Вступление

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

Эта статья расшифровка видеодоклада Алексея Вахова из Учи.ру «Облака в облаках»

Учи.ру — онлайн-платформа для школьного образования, более 2 миллионов школьников, регулярно решают у нас интерактивные занятия. Все наши проекты хостятся полностью в публичных облаках, 100% приложений работают в контейнерах, начиная от самых маленьких, для внутреннего пользования, и заканчивая крупными продакшенами на 1k+ запросов в секунду. Так получилось, что у нас 15 изолированных докер-кластеров (не Kubernetes, sic!) в пяти облачных провайдерах. Полторы сотни пользовательских приложений, количество которых постоянно растет.

Я буду рассказывать очень конкретные вещи: как мы переходили на контейнеры, как управляемся с инфраструктурой, проблемы с которыми столкнулись, что заработало, а что нет.

В процессе доклада мы обсудим:

• Мотивацию выбора технологий и особенности бизнеса
• Инструменты: Ansible, Terraform, Docker, Github Flow, Consul, Nomad, Prometheus, Shaman — web-интерфейс для Nomad.
• Использовании федерации кластеров для управления распределенной инфраструктурой
• NoOps выкатки, тестовые окружения, схемы приложения (практически все изменения девелоперы делают самостоятельно)
• Занимательные истории из практики

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

Пришла задача WEB-12982
Создаешь ветку web-12982 в репозитории
Пока ветка собирается, читаешь тз и пьешь кофе
Приступаешь непосредственно к разработке

git commit, git push
Пока ветка пересобирается листаешь хабр
git commit, git push
Пока ветка пересобирается листаешь твиттер
git commit, git push
…
Сдаешь на ревью ветку с 50 коммитами

Понимаешь, что 50 коммитов — это ровно 50 минут чистого времени, которое собрано урывками, потому что отрезки по 1 минуте слишком малы, чтобы заниматься чем-то, кроме прокрастинации и элементарных потребностей.

Знакома ситуация? В моей компании инфраструктура разработки организована таким образом:

• В гитлабе есть множество репозиториев по проектам
• Чтобы обеспечить удобство разработки при создании новой ветки автоматически докерами создается своя песочница по уникальному адресу, полная копия родительской ветки со всем необходимым окружением.
• Все, что нужно, уже готово — просто пиши код и тестируй-смотри-оценивай результат после каждого коммита, очень удобно!

Но, медленно... Если тебе близка эта ситуация, добро пожаловать под кат.