У серпні ми з друзями літали в Ісландію. Як це часто буває у довгих поїздках – з кожним днем зміст розмов скочується на, здавалося б, вже пробите дно. І от десь на 8-ий день подорожі, переїжджаючи через черговий гірський масив, ми завели тривалу дискусію про ісландських баранів. В Ісландії. Дискусія. Про баранів. На 4(!) години. А все чому? Відколи ми виїхали з міста Кефлавік, нам траплялися по дорозі безліч невеличких груп баранів. І особливість цих груп заключалася у тому, що їх в 90% випадків було троє. Ні, вони не зв’язані нічим, вільні ходити по безкраїх просторах прибережних зон, рівнин та гір. Але завжди, завжди три барани. Ми, інколи, зупинялися, коли бачили двох баранів і не рушали, поки не знайшли за якимось каменем третього. Така собі константа ісландська. Що трапилося на 8-ий день? Ця схема зовсім поламалася. Ми бачили баранів, які гуляли і по одному, і по двоє, і по троє і, навіть по четверо. Але не більше чотирьох. Власне, ця смішна обставина і збурила дискусію.

В результаті тривалих суперечок, ми прийшли до такого висновку. Три – це нормальна кількість баранів у групі. Але, як характерно для загального поняття груп людей/тварин – компанії змінюються. Наприклад, один баран переріс свою компанію – йому не подобаються території, на яких група випасається, йому не подобається напрямок, у якому вони просуваються та і не комфортно йому з теперішньою групою. Тож цей баран виходить з групи і йде шукати іншу. Звідси, власне, з’являються поодинокі барани та групи з двох баранів. Ці одинаки разом з молодими баранами, які тільки починають свій шлях, шукають нову групу. Буває так, що вони знаходять іншу групу з трьох баранів, приєднуються до неї, І їх стає четверо. При цьому, новоприбулий баран може давати групі більше, ніж хтось з діючих членів команди, тому, на якомусь етапі, нова коаліція може виперти когось із старих непотрібних баранів, оскільки вони хочуть рухатися в іншому напрямку, а цей один їм заважає та гальмує весь процес. Така от смішна дискусія в нас вийшла про те, звідки беруться один, два, три чи чотири барани в групах. А тепер про важливе – до чого тут кар’єризм?

Я працюю devops-інженером у компанії GlobalLogic. Прийшов сюди у серпні, переїхавши з Тернополя у Львів. Мені зовсім чужа ця політика аутсорсингових компаній визначати рівні розробників за якимось матрицями, що не мають жодного стандарту та утвердженої форми. Але гаразд, якщо компанії треба продавати людей і якось ранжувати ціну за них – поділ має бути. Хоча внутрішній. Чи це говорить щось про рівень технічних чи софт скілів працівника? Не маю певності в цьому. Це як сертифікації – ти готуєшся і здаєш, але про що говорить твій сертифікат – про пам’ять чи про навики – невідомо. Тим не менш, багатьом іт-спеціалістам важливо чи вони junior чи senior чи tech lead і всяке таке. З цього природнього бажання бути кращим за інших виникає багато розмов про те, що в одній компанії спеціалісти у тому ж званні гірші за спепціалістів на аналогічних позиціях іншої компанії. Щось на зразок того, що сержанти української армії стріляють гірше, ніж сержанти армії США. Так як в мене досить багато знайомих із ІТ-компаній Львова, то чую я таку думку дуже часто. Фрази накшталт “А, GlobalLogic – вони, навіть, не в першій п’ятірці”, “Lohika – ну та, вони дуже круті”, “О, зараз я middle на Epam-і, але на SoftServe вже була б senior-ом”, “Eleks – пфф, краще піду розвантажувати вагони”. Що там знайомі, я і в офісі своєї компанії чую такі думки. Бекенд-, фронтенд розробники, тестери, аналітики та іншого роду інженери узагальнюють інформацію про компанію до таких от примітивних трактувань. Насправді ж, кожна з компаній має штат висококласних спеціалістів у всіх сферах ІТ, завдяки яким замовлення продовжують приходити, що дозволяє цим компаніям набирати більше і більше людей. І, звісно ж, не всі з новоприйнятих одразу починають вносити свій внесок у позитивний рейтинг. Але як би цей аутсорс працював, якби в ньому справді були такі далекі спеціалісти, як про них відгукуються колеги з інших компаній?

Так склалися обставини – час, гроші, проект, рівень команди – що той, чи інший спеціаліст потрапив саме сюди. І, в першу чергу, від відношення до роботи залежить його професійний розвиток, а не від складності бюрократичних процедур по отриманню того чи іншого бейджа з ціною, яку має за тебе заплатити замовник. А ще команда. Твоя група баранів (жодних образ, я і себе сюди зачисляю). Якщо ви як один серйозно відноситесь до поставлених завдань, добре ладите один з одним, прагнете розвинути себе та своїх колеги, а проект та його менеджмент вам у цьому допомагають – ваша група тримається. Якшо ви почуваєте себе некомфортно – шукайте нову групу. Якщо ви не хочете розвиватись, але і йти не хочете – дочекайтесь новоприбулих “баранів”, співпраця з якими принесе команді набагато більше задоволення і вона сама випре вас на пошуки нового незвіданого. А ви втратите час, що, є надто цінним ресурсом, аби так просто ним розкидатись. Якось так.

Головна ціль Otto – спростити життя розробникам і позбавити їх необхідності дружити з DevOps-ами. Жартую, звісно) Але це той випадок, коли автоматизація направлена в правильне русло. Адже з Otto вам не треба буде будувати образи з Packer-ом, описувати конфігурації для деплою в Terraform, що вимагає розрахунку потужностей для архітектури ваших сервісів та інші devops-related задачі. На презентації продукту Хашимото користувався терміном “муміфікація”, описуючи відмінність між Vagrant та Otto. Мається на увазі, що за допомогою описаної конфігурації Vagrant/Packer/Terraform інші розробники зможуть розгорнути те ж саме середовище, як і ви в будь який момент часу. Але відповідальність за те, що використовувані ресурси чи параметри взаємодії з клаудами застаріють ви повинні брати на себе. Otto все це бере на себе. Просто скажіть яка мова у вашому проекті використовується, які бази даних (чи інші мікросервіси) використовуються в преокті, які порти треба прокласти в паблік, в який клауд деплоїти – і це все один єдиний конфігураційний файл, який можна зберігати в CVS і перейматися лише розробкою, а не розгортанням інфраструктури. На даний момент Otto працює лише з Ruby проектами, тому продовження матеріалу переноситься на потім, коли буде додана підтримка Python.

А поки – поговоримо про інший продукт HashiCorp, який був представлений разом з Otto і має, імхо, більше значення для DevOps світу, ніж Otto. Що це таке, для чого тут кластери і як з цим усім жити? Про це далі.

Так уже завернула професійна кар’єра, що блог перепрофілювався суто на DevOps тематику і, зокрема, популярні в наш час архітектури, орієнтовані на мікросервіси взамін монолітним системам. В попередніх матеріалах я багато писав про платформи для запуску вашої інфраструктури, про автоматичне розгортання інфраструктури, підготовку образів, оркестрацію. Але як цією кухнею керувати після запуску? Як її гнучко масштабувати, локалізовувати ресурси? Вирішенням саме цих непростих питань займається Nomad. І робить він це прозоро поверх віддалених датацентрів у різних регіонах. Все як у дорослих.

HashiCorp не зраджує своїм традиціям і надає нам можливість описувати всю інфраструктуру одним файлоа конфігурації, в який можна передавати параметри як через environment документ із змінними, так і через параметри в консолі. Власне, го до прикладу.

Кластер Nomad працює через комунікацію агентів на кожній з машин у кластері. Агенти можуть працювати у режимі сервера та клієнта. За рекомендаціями HashiCorp на кожен окремий регіон у вас має бути один серверний агент. Так як мені аби попробувати – то я запущу один інстанс в development режимі, що включає в себе і сервер і клієнт одночасно.

root@vagrant-ubuntu-vivid-64:/opt/hashicorp# nomad agent -dev
==> Starting Nomad agent...
2015/11/24 07:50:12 [ERR] fingerprint.env_aws: Error querying AWS Metadata URL, skipping
==> Nomad agent configuration:

                 Atlas: <disabled>
                Client: true
             Log Level: DEBUG
                Region: global (DC: dc1)
                Server: true

root@vagrant-ubuntu-vivid-64:~# nomad node-status
ID                                    DC   Name                     Class   Drain  Status
9696a23d-5daf-b210-098e-7699881f5f0e  dc1  vagrant-ubuntu-vivid-64  <none>  false  ready

root@vagrant-ubuntu-vivid-64:~# nomad server-members
Name                            Addr       Port  Status  Proto  Build  DC   Region
vagrant-ubuntu-vivid-64.global  127.0.0.1  4648  alive   2      0.2.0  dc1  global

Статус сервісу показує, що він запущений одночасно як клієнт і як сервер ат приєднаний то датацентру dc1 в регіоні global. Клієнти у кластері спілкуються через так званий gossip-протокол, який має бути знайомий вам за роботою із Serf (припускаю, що якщо вас зацікавив Nomad – то Serf ви теж бачили, адже це один з найпопулярніших продуктів HashiCorp). Його схему автори описують прикладом зомбі-апокаліпсису – спочатку “заражений” один інстанс, потім іде обмін повідомленнями між агентами аж поки всі не стануть частиною кластера.

Маючи робочий кластер, ми можемо запустити якусь задачу на ньому. В термінології Nomad – це job, що є по суті декларативним описом завдань, які Nomad має виконати.
Приклад ініціалізації шаблону для завдання та його виконання на Nomad-і:

root@vagrant-ubuntu-vivid-64:/opt/nomad# nomad init
Example job file written to example.nomad
root@vagrant-ubuntu-vivid-64:/opt/nomad# nomad init itblogger
Usage: nomad init

  Creates an example job file that can be used as a starting
  point to customize further.
root@vagrant-ubuntu-vivid-64:/opt/nomad# vim example.nomad
root@vagrant-ubuntu-vivid-64:/opt/nomad# ls
example.nomad
root@vagrant-ubuntu-vivid-64:/opt/nomad# nomad run example.nomad
==> Monitoring evaluation "63f8d898-0dbd-a498-bb9e-1607324567ed"
    Evaluation triggered by job "example"
    Allocation "9634380b-01b9-26f4-3d5a-cb59a68262a5" created: node "9696a23d-5daf-b210-098e-7699881f5f0e", group "cache"
    Evaluation status changed: "pending" -> "complete"
==> Evaluation "63f8d898-0dbd-a498-bb9e-1607324567ed" finished with status "complete"

Для запску прикладу якоїсь реальної задачі земулюємо реальний кластер із окремим сервером та клієнтом.
Конфігурація сервера server.hcl (детально про Hashicorp Configuration Language HCL)

# Increase log verbosity
log_level = "DEBUG"

# Setup data dir
data_dir = "/tmp/server1"

# Enable the server
server {
    enabled = true

    # Self-elect, should be 3 or 5 for production
    bootstrap_expect = 1
}

Це мінімальна конфігруація, якої достатньо для запуску одного сервера та вибору його лідером кластеру:

root@vagrant-ubuntu-vivid-64:/opt/nomad# nomad agent -config server.hcl
==> WARNING: Bootstrap mode enabled! Potentially unsafe operation.
==> Starting Nomad agent...
==> Nomad agent configuration:

                 Atlas: <disabled>
                Client: false
             Log Level: DEBUG
                Region: global (DC: dc1)
                Server: true

Додамо в кластер два клієнти:

Конфігурація клієнта #1 client1.hcl
# Increase log verbosity
log_level = "DEBUG"

# Setup data dir
data_dir = "/tmp/client1"

# Enable the client
client {
    enabled = true

    # For demo assume we are talking to server1. For production,
    # this should be like "nomad.service.consul:4647" and a system
    # like Consul used for service discovery.
    servers = ["127.0.0.1:4647"]
}

# Modify our port to avoid a collision with server1
ports {
    http = 5656
}

Конфігурація клієнта #2 client2.hcl

# Increase log verbosity
log_level = "DEBUG"

# Setup data dir
data_dir = "/tmp/client2"

# Enable the client
client {
    enabled = true

    # For demo assume we are talking to server1. For production,
    # this should be like "nomad.service.consul:4647" and a system
    # like Consul used for service discovery.
    servers = ["127.0.0.1:4647"]
}

# Modify our port to avoid a collision with server1
ports {
    http = 5657
}

Запускаємо процеси для клієнтів по аналогії із сервером передаючи як параметр конфігурації client1.hcl та client2.hcl. Отримуємо робочий кластер:

root@vagrant-ubuntu-vivid-64:/opt/nomad# nomad node-status
ID                                    DC   Name                     Class   Drain  Status
2f600d8d-0775-b65e-c310-7f6d5f1a1e90  dc1  vagrant-ubuntu-vivid-64  <none>  false  ready
1421228e-54a5-70d1-684d-b7ef278e2784  dc1  vagrant-ubuntu-vivid-64  <none>  false  ready
root@vagrant-ubuntu-vivid-64:/opt/nomad# nomad server-members
Name                            Addr       Port  Status  Proto  Build  DC   Region
vagrant-ubuntu-vivid-64.global  127.0.0.1  4648  alive   2      0.2.0  dc1  global 

Звісно, в production-середовищі всі ip-адреси будуть замінені на discovery-параметри від Consul-а чи іншого сервісу накшталт Zookeper чи etcd.

Останній крок – запуск demo-job на новоствореному кластері. init процес генерує приклад із redis, тож я не буду ускладнювати собі життя і запущу це ж завдання example.nomad. Єдиний параметр, який я змінив – count для групи ресурсів “cache”:

        group "cache" {
                # Control the number of instances of this groups.
                # Defaults to 1
                count = 4
 

Запускаємо job:

root@vagrant-ubuntu-vivid-64:/opt/nomad# nomad run example.nomad
==> Monitoring evaluation "7816ee41-8d84-2f3f-7a6e-5a8360980389"
    Evaluation triggered by job "example"
    Scheduling error for group "cache" (failed to find a node for placement)
    Allocation "d3db07e7-b11f-13b9-82d8-6f37ddf3f435" status "failed" (0/2 nodes filtered)
      * Resources exhausted on 2 nodes
      * Dimension "memory exhausted" exhausted on 2 nodes
    Allocation "fcc3bb0a-4766-2d41-a421-91b473a4f57e" created: node "1421228e-54a5-70d1-684d-b7ef278e2784", group "cache"
    Allocation "ca5ac406-1fea-8dfd-3893-9d7704ed0a3d" modified: node "2f600d8d-0775-b65e-c310-7f6d5f1a1e90", group "cache"
    Evaluation status changed: "pending" -> "complete"
==> Evaluation "7816ee41-8d84-2f3f-7a6e-5a8360980389" finished with status "complete"

Зверніть увагу – оперативної пам’яті вистачило лише на два з чотирьох контейнерів. Тим не менш cache-cluster стартовано на доступних ресурсах:

root@vagrant-ubuntu-vivid-64:/opt/nomad# docker ps
CONTAINER ID        IMAGE               COMMAND                CREATED              STATUS              PORTS                                                              NAMES
2d417223b4e5        redis:latest        "/entrypoint.sh redi   50 seconds ago       Up 49 seconds       10.0.2.15:53141->53141/tcp, 6379/tcp, 10.0.2.15:53141->53141/udp   redis-fcc3bb0a-4766-2d41-a421-91b473a4f57e
e4322f0e5d30        redis:latest        "/entrypoint.sh redi   About a minute ago   Up About a minute   6379/tcp, 10.0.2.15:47099->47099/udp, 10.0.2.15:47099->47099/tcp   redis-ca5ac406-1fea-8dfd-3893-9d7704ed0a3d
root@vagrant-ubuntu-vivid-64:/opt/nomad# vim example.nomad
root@vagrant-ubuntu-vivid-64:/opt/nomad# nomad status example
ID          = example50
Name        = example
Type        = servicer job to only linux. We can specify multiple
Priority    = 50aints as needed.
Datacenters = dc1t {
Status      = <none>ibute = "$attr.kernel.name"
                value = "linux"
==> Evaluations
ID                                    Priority  TriggeredBy   Status
7816ee41-8d84-2f3f-7a6e-5a8360980389  50        job-register  complete
12531fab-3ff4-77c0-e5b5-3178d7d017a0  50        job-register  complete
                # Stagger updates every 10 seconds
==> Allocations stagger = "10s"
ID                                    EvalID                                NodeID                                TaskGroup  Desired  Status
d3db07e7-b11f-13b9-82d8-6f37ddf3f435  7816ee41-8d84-2f3f-7a6e-5a8360980389  <none>                                cache      failed   failed
fcc3bb0a-4766-2d41-a421-91b473a4f57e  7816ee41-8d84-2f3f-7a6e-5a8360980389  1421228e-54a5-70d1-684d-b7ef278e2784  cache      run      running
ca5ac406-1fea-8dfd-3893-9d7704ed0a3d  7816ee41-8d84-2f3f-7a6e-5a8360980389  2f600d8d-0775-b65e-c310-7f6d5f1a1e90  cache      run      running

Nomad кластер має вбудований scheduler, який моніторить ресурси і при їх доступності запустить додаткові контейнери відповідно до конфігурації. Також, можна на ходу змінювати конфігурацію завдання, наприклад, додавши більше worker-ів, або змінивши версію redis-а. В приведеній конфігурації кластер перевірятиме опис завдання кожних 10 секунд, що, звісно, не заважає форсувати оновлення завдання запустивши його через команду nomad run повторно.

Підсумовуючи – в мереж і я натрапив на велику кількість невдоволених відгуків стосовно Nomad. Їх суть була в тому, що користувачі не розуміють мети, якої прагне досягнути HashiCorp з продуктами на зразок Nomad, коли на ринку є Kubernetes та Mesos, які підтримуються такими гігантами як Google та Apache відповідно. Особисто моя думка – немає нічого поганого в альтернативах. Ті користувачі, які зуміли пристосувати до автоматизації своїх процесів Terraform, Consul, Serf – знають, що HashiCorp роблять дуже devops-oriented продукти, які відповідають вимогам часу та модернових процесів організації інфраструктури. З іншого боку, HashiCorp – відносно невелика контора, тому ідея концентрації на вже існуючих продуктах теж зрозуміла. В мене немає певності, що Nomad зможе якось конкурувати із інсталяцією Kubernetes over Mesos для масштабних проектів. А використання Nomad якраз орієнтоване на великі розподілені інфраструктури. Але успіх попередніх продуктів вселяє надію на те, що і Nomad знайде свого користувача.

Отже, Terraform дозволяє описувати, а потім білдити та розгортати інфраструктуру на базі декількох датацентрів без прив’язки до технологій хмарного провайдера. Наприклад, ви описуєте ресурси EC2 в AWS та дроплета в Digital Ocean, доступ до яких здійснюватиметься через якийсь DynDNS сервіс. І це все – в декілька рядків конфігураційного коду. Про ресурси я згадав недарма – саме такою термінологією користується Terraform. Наприклад:

resource "digitalocean_droplet" "web" {
   name = "tf-web"
   size = "512mb"
   image = "centos-5-8-x32"
   region = "sfo1"
}

resource "dnsimple_record" "hello" {
   domain = "example.com"
   name = "test"
   value = "${digitalocean_droplet.web.ipv4_address}"
   type = "A"
}

10 рядків конфігурації, з яких генерується план досягнення описаного стану інфтраструктури. Після його виконання у вас є запущений дроплет Centos та А-запис із його ip-адресою для DNSSimple.

Перейдемо до якогось практичнішого прикладу. Наприклад, запуск двох веб-серверів із балансуванням через haproxy.
На цей момент у вас має бути зареєстрований акаунт в Digital Ocean, доданий публічний ключ в налаштуваннях та згенерований Personal access token. Як у і випазку з Packer-ом – змінні можна передавати прямо в командному рядку, але грамотно і зручніше це робити через файли зі змінними.

Починаємо з декларування. Навідміну від Packer-а, в Terraformi-і можна описувати список обов’язкових та необов’язкових змінних, які потім можна додавати або з файла, або з командного рядка. Тому першим треба додати файлик зі список необхідних змінних:

variables.tf

variable "do_token" {}
variable "pub_key" {}
variable "pvt_key" {}
variable "ssh_fingerprint" {}

provider "digitalocean" {
  token = "${var.do_token}"
}

Називати файл можна довільно, головне зберігати розширення *.tf, оскільки саме файли цього формату будуть підхоплені під час білду.

Наступним додамо файл, власне, із значеннями:

terraform.tfvars

DO_PAT = "cd85a4fdbf88xxxxxxxxxxxxxxxxxxxx1f41cd8dc43a"
pub_key = "D:\Projects\private\prj\access\digitalocean.pub"
pvt_key = "D:\Projects\private\prj\access\digitalocean"
ssh_fingerprint = "f8:eb:40:bxxxxxxxxxxxxxxxxxxxx13:3d:22:27"

Файл terraform.tfvars за замовчуванням читається Terraform-ом. Якщо файл матиме інше ім’я – його потрібно буде вказати в командному рядку при виконанні через -var-file.

Кожен провайдер має свою специфікацію, відповідно, до якої відбувається виклик API обраного провайдера. У випадку Digital Ocean нам доступні три типи ресурсів:

• digitalocean_domain
• digitalocean_droplet
• digitalocean_record

Конфігурація дроплета першого веб-сервера:

www-1.tf

resource "digitalocean_droplet" "www-1" {
    image = "ubuntu-14-04-x64"
    name = "www-1"
    region = "nyc2"
    size = "512mb"
    private_networking = true
    ssh_keys = [
      "${var.ssh_fingerprint}"
    ]

    connection {
      user = "root"
      type = "ssh"
      key_file = "${var.pvt_key}"
      timeout = "2m"
  }

    provisioner "remote-exec" {
    inline = [
      "export PATH=$PATH:/usr/bin",
      # install nginx
      "sudo apt-get update",
      "sudo apt-get -y install nginx"
    ]
  }
}

Коротко по блоках:

• конфігурація дроплета
• спосіб підключення
• shell-provisioning

В результаті виконання terraform plan отримуємо:

$ terraform plan
Refreshing Terraform state prior to plan...


The Terraform execution plan has been generated and is shown below.
Resources are shown in alphabetical order for quick scanning. Green resources
will be created (or destroyed and then created if an existing resource
exists), yellow resources are being changed in-place, and red resources
will be destroyed.

Note: You didn't specify an "-out" parameter to save this plan, so when
"apply" is called, Terraform can't guarantee this is what will execute.

+ digitalocean_droplet.www-1
    image:                "" => "ubuntu-14-04-x64"
    ipv4_address:         "" => "<computed>"
    ipv4_address_private: "" => "<computed>"
    ipv6_address:         "" => "<computed>"
    ipv6_address_private: "" => "<computed>"
    locked:               "" => "<computed>"
    name:                 "" => "www-1"
    private_networking:   "" => "1"
    region:               "" => "nyc2"
    size:                 "" => "512mb"
    ssh_keys.#:           "" => "1"
    ssh_keys.0:           "" => "f8:eb:40:b4xxxxxxxxxxxxxxxxxd:22:27"
    status:               "" => "<computed>"


Plan: 1 to add, 0 to change, 0 to destroy.

Підготуємо ще один дроплет із аналогічною конфігурацією:

www-2.tf

resource "digitalocean_droplet" "www-1" {
    image = "ubuntu-14-04-x64"
    name = "www-1"
    region = "nyc2"
    size = "512mb"
    private_networking = true
    ssh_keys = [
      "${var.ssh_fingerprint}"
    ]

    connection {
      user = "root"
      type = "ssh"
      key_file = "${var.pvt_key}"
      timeout = "2m"
  }

    provisioner "remote-exec" {
    inline = [
      "export PATH=$PATH:/usr/bin",
      # install nginx
      "sudo apt-get update",
      "sudo apt-get -y install nginx"
    ]
  }
}

Ну і наостанок – haproxy для балансування навантаження.

aproxy-www.tf

resource "digitalocean_droplet" "haproxy-www" {
    image = "ubuntu-14-04-x64"
    name = "haproxy-www"
    region = "nyc2"
    size = "512mb"
    private_networking = true
    ssh_keys = [
      "${var.ssh_fingerprint}"
    ]

    connection {
      user = "root"
      type = "ssh"
      key_file = "${var.pvt_key}"
      timeout = "2m"
  }

  provisioner "remote-exec" {
    inline = [
      "export PATH=$PATH:/usr/bin",
      # install haproxy 1.5
      "sudo add-apt-repository -y ppa:vbernat/haproxy-1.5",
      "sudo apt-get update",
      "sudo apt-get -y install haproxy",

      # download haproxy conf
      "sudo wget https://gist.githubusercontent.com/corest/c51df9444a717ab210c9/raw/bc2b8cc1335b3e37c9bebb47bae70abf963f0c67/haproxy.cfg -O /etc/haproxy/haproxy.cfg",

      # replace ip address variables in haproxy conf to use droplet ip addresses
      "sudo sed -i 's/HAPROXY_PUBLIC_IP/${digitalocean_droplet.haproxy-www.ipv4_address}/g' /etc/haproxy/haproxy.cfg",
      "sudo sed -i 's/WWW_1_PRIVATE_IP/${digitalocean_droplet.www-1.ipv4_address_private}/g' /etc/haproxy/haproxy.cfg",
      "sudo sed -i 's/WWW_2_PRIVATE_IP/${digitalocean_droplet.www-2.ipv4_address_private}/g' /etc/haproxy/haproxy.cfg",

      # restart haproxy to load changes
      "sudo service haproxy restart"
    ]
  }
}

Я не зупиняюся надто на коментуванні вмісту конфігурацій, оскільки, вони мають дуже простий формат і є, як то кажуть, self-explanatory. Загальна логіка файла конфігурації haproxy схожа з дроплетами для веб-серверів: описати ноду, сконфігурувати спосіб підключення до неї, налаштувати сервіс haproxy із параметрами приватних ip-адрес та публічної ip-адреси, які будуть вирахувані після запуску дроплетів (кожен тип ресурсу має свої дані, які експортуються після завершення деплою ресурсу).

Останнім кроком додамо DNS записи для нашої конфігурації.

terraform.itblogger.org.ua.tf

# Create a new domain record
resource "digitalocean_domain" "default" {
   name = "terraform.itblogger.org.ua"
   ip_address = "${digitalocean_droplet.haproxy-www.ipv4_address}"
}

resource "digitalocean_record" "CNAME-www" {
  domain = "${digitalocean_domain.default.name}"
  type = "CNAME"
  name = "www"
  value = "@"
}

Можна білдити:

terraform apply

В результаті отримуємо haproxy-сервер, доступний назовні, який балансує запити між двома нодами в приватный мережі.

А тепер підемо трохи далі і додамо тієї самої кросс-платформенності. Наприклад, наша задача – збільшити кількість нод, аби через деякий час без зупинки роботи інфраструктури мігрувати з Digital Ocean на AWS. Для цього додамо ще ноду веб-сервера, але вже на AWS.

Почати варто із змінних для доступу та налаштування.

provider.tf

variable "do_token" {}
variable "pub_key" {}
variable "pvt_key" {}
variable "ssh_fingerprint" {}

variable "aws_access_key" {}
variable "aws_secret_key" {}
variable "source_ami" {}
variable "instance_type" {}
variable "associate_public_ip_address" {}
variable "aws_key_pair" {}
variable "aws_region" {
    default = "us-west-2"
}

provider "digitalocean" {
  token = "${var.do_token}"
}

provider "aws" {
    access_key = "${var.aws_access_key}"
    secret_key = "${var.aws_secret_key}"
    region = "${var.aws_region}"
}

Ну і файл із значеннями (не забудьте імортувати ваш публічний ключ в AWS):

terraform.tfvars

"do_token" = "cd85a4fdbf8805cc2dbfxxxxxxxxxxxxx1bf1f41cd8dc43a"
"pub_key" = "D:\Projects\private\prj\access\digitalocean.pub"
"pvt_key" = "D:\Projects\private\prj\access\digitalocean"
"ssh_fingerprint" = "f8:eb:40:b4:05:d2:fa:0d:06:b0:55:c9:13:3d:22:27"
"aws_access_key" = "AKIAJxxxxxxxxxxxxxVWLA"
"aws_secret_key" = "Z4i6Zxxxxxxxxxxxxxxxxx0BVz/xYraS"
"aws_key_pair" = "do_import"
"source_ami" = "ami-5189a661"
"instance_type" = "t2.micro"
"associate_public_ip_address" = "true"

Перед тим, як додати конфігурацію EC2-ноди, варто створити новий ресурс security-групи, оскільки на даний момент Terraform не підтримує імпорту вже існуючих груп (тоді можна було б використати групу, створену Packer-ом у попередньому матеріалі).

aws_security_group.tf

resource "aws_security_group" "allow_all" {
  name = "allow_all"
  description = "Allow all inbound traffic"

  ingress {
      from_port = 0
      to_port = 0
      protocol = "-1"
      cidr_blocks = ["0.0.0.0/0"]
  }

  egress {
      from_port = 0
      to_port = 0
      protocol = "-1"
      cidr_blocks = ["0.0.0.0/0"]
  }
}

Як бачите, нічого спільного із security ця група немає, адже вона дозволяє весь трафік на вхід і на вихід. Але для експерименту цього достатньо.

Третій крок – власне, сама нода.

www-3.tf

resource "aws_instance" "www-3" {
    ami = "${var.source_ami}"
    instance_type = "${var.instance_type}"
    tags {
        Name = "www-3"
    }

    depends_on = ["aws_security_group.allow_all"]
    
    security_groups = ["${aws_security_group.allow_all.id}",]    


    key_name = "${var.aws_key_pair}"


    connection {
      user = "ubuntu"
      type = "ssh"
      key_file = "${var.pvt_key}"
      timeout = "2m"
  }

    provisioner "remote-exec" {
    inline = [
      "export PATH=$PATH:/usr/bin",
      # install nginx
      "sudo apt-get update",
      "sudo apt-get -y install nginx"
    ]
  }
}

Ця конфігурація використовує id значення security-групи, яке буде експортовано для використання після створення групи.

Останні зміни: в конфігурації haproxy-ноди – додати рядок для щаміни шаблону на публічну адресу EC2-інстанса (після повної міграції також можна перейти на приватні адреси).

haproxy-www.tf

      "sudo sed -i 's/WWW_3_PUBLIC_IP/${aws_instance.www-3.public_ip}/g' /etc/haproxy/haproxy.cfg",

і шаблон в конфігурацію haproxy:

haproxy.cfg

  server www-3 WWW_3_PUBLIC_IP:80 check

Виконуємо білд, і через декілька хвилин у нас оновлена інфраструктура із трьома нодами вебсерверів на різних хмарних провайдерах:

  ip_address: "" => "162.243.93.231"
  name:       "" => "terraform.itblogger.org.ua"
digitalocean_domain.default: Creation complete
digitalocean_record.CNAME-www: Creating...
  domain:   "" => "terraform.itblogger.org.ua"
  name:     "" => "www"
  port:     "" => "<computed>"
  priority: "" => "<computed>"
  type:     "" => "CNAME"
  value:    "" => "@"
  weight:   "" => "<computed>"
digitalocean_record.CNAME-www: Creation complete

Apply complete! Resources: 6 added, 0 changed, 0 destroyed.

The state of your infrastructure has been saved to the path
below. This state is required to modify and destroy your
infrastructure, so keep it safe. To inspect the complete state
use the `terraform show` command.

State path: terraform.tfstate

Те, що робить Мітчел Хашимото та його компанія – дуже прогресивна річ. Навіть, порівняно із вже незамінними конфігураційними менеджерами. Як сказав сам Хашимото на одній з недавніх конференцій: “Ви можете мати скільки завгодно автоматизації для налаштування вашого продукту, але поки у вас немає автоматичного розгортання сервісів – який сенс у цьому? Ваш продукт не працюватиме.”. Еволюція devops-у іде семимильними кроками. Після традиційного bash-provisioning компанії стрімко інтегрували Puppet-и та Chef-и із своїми продуктовими API та SDK. Але Terraform – це ще вищий рівень абстракції. Я не маю на увазі, що вам обов’язково треба зав’язувати концентрувати увагу саме на цьому рівні, але грамотне поєднання кращих практик безумовно зекономить час, гроші та нерви у завданнях організації та управлінні інфраструктурою ваших сервісів. А Terraform – вже зараз у списку кращих практик кожного devops-а, який тримає руку на пульсі свого галузевого напрямку.

Ну і третя. IAAS  взяла найвищий пріоритет завдяки одній із співбесід, яку я мав змогу проходити в процесі пошуку роботи. Компанію не називатиму, але суть розмови зводилася до порівняння різних клауд-провайдерів та технологій віртуалізації. Серед основних питань, з приводу яких виникла дискусія – складність тестування інфрастуктури через пропрієтарність деяких форматів шаблонів обчислювальних ресурсів (AMI в AWS, наприклад) та використання різних хмарних провайдерів у одному проекті. Звісно, це не common case, але за це я і люблю проходити співбесіди кожного місяця незалежно від того чи шукаю роботу, чи ні.

Менше води. Використання різних технологій віртуалізації приводить нас до ситуації, коли взяти і запустити відтестовану локальну машину в хмарі – зовсім нетривіальна задача. Звісно, для цього і з’явилися на ринку десятки інструментів оркестрації, а пізніше – і тотальна docker-изація, яка потроху стає новим стандартом для software-delivery. Але процес цей має свої підводні камені, тому єдиний формат опису конфігурації обчислювальних ресурсів різних хмарних провайдерів досі залишається актуальною проблемою. Яку і вирішує Packer від HashiCorp.

Я не зупинятимусь надто довго над описом команд це все є в документації. Тому, перейду одразу до практичного прикладу.

Декілька слів про термінологію:

• build – побудо образу машини для однієї платформи
• artifacts – результат виконання build-а
• builder – компонент, що використовується для виконання build-а для обраної платформи. Приклад builder-а: Vmware, Amazon EC2.
• provisioner – компонент, що виконує налаштування зібраного білда (Puppet, shell etc.)
• template – власне, та сама уніфікована конфігурація, білд якої дає нам артефакти

Типова конфігурація шаблону:

{
  "variables": {
    "var_name": "var_value"
  },
  "builders": [
    { "type": "virtualbox-iso" },
    { "type": "digitalocean" },
    { "type": "amazon-instance" }
  ],
  "provisioners": [
    { "type": "shell" },
    { "type": "ansible-local" }
  ],
  "post-processors": [
    { "type": "compress" }
  ]
}

Щодо секції “variables” – звісно, тримати важливі дані доступу у файлі шаблону не рекомендується. Їх можна передати як параметр білда окремим файлом.

Для прикладу – приводжу файл зі змінними, які необхідно задати для білду AMI (Amazon Machine Instance).

variables.json

{
  "aws_access_key": "AKIAxxxxxxxxUXVWLA",
  "aws_secret_key": "Z4i6ZpdHrW9xxxxxxxxxxxxxxxx0BVz/xYraS",
  "aws_region": "us-west-2",
  "source_ami": "ami-5189a661",
  "instance_type": "t2.micro",
  "ssh_username": "ubuntu",
  "ami_name": "ITBlogger packer build",
  "security_group_id": "sg-7xxxxx1x",
  "user_pass": "ubuntu",
  "hostname": "ITBlogger",
  "web_server_ip": "192.168.56.1",
  "web_server_port": "8080"
}

Файл містить перелік необхідних полів. Насправді ж, доступних налаштувань набагато більше. Серед перелічених – всі до ami_name включно є обов’язковими. security_group_id створюється у процесі білда, але лише з ssh inbound rule. Оскільки, в нас буде веб-сервер – потрібно створити свою групу з доступом для ssh та http і додати id цієї групи у конфігурацію. З списком налаштувань можна ознайомитись тут тут. Щодо web_server_ip та web_server_port – ці значення додані для майбутнього розгортання білда через virtualbox.

Використовуючи файл зі змінними, тепер шаблон можна подати у такому вигляді:

template.json

{
  "builders": [{
    "type": "amazon-ebs",
    "access_key": "{{user `aws_access_key`}}",
    "secret_key": "{{user `aws_secret_key`}}",
    "region": "{{user `aws_region`}}",
    "source_ami": "{{user `source_ami`}}",
    "instance_type": "{{user `instance_type`}}",
    "ssh_username": "{{user `ssh_username`}}",
    "tags": {
      "OS_Version": "Ubuntu 14.04"
    },
    "ami_name": "{{user `ami_name`}} [{{timestamp}}]",
    "ami_description": "Test build for itblogger post about packer",
    "security_group_id": "{{user `security_group_id`}}",
  }],
  "provisioners": [
    { 
      "type": "shell",
      "script": "bootstrap.sh",
      "override": {
        "amazon-ebs": {
          "execute_command": "echo {{user `user_pass`}}  | sudo -S sh '{{ .Path }}'"
        }
      }
      }
  ]
}

Зверніть увагу, що порядок у файлі зі змінними має збігатися із порядком їхнього використання в шаблоні, бо в іншому випадку шаблон не пройде валідацію.
Поки що сенсу в цій конфігурації мало, адже все, що ми робимо – це переводимо один AMI в інший. Тому додамо якогось provisioning-у. Packer підтримує безліч конфігураційних менеджерів і я особито віддаю перевагу Ansible, але щоб не зачіпати надто багато інструментів та технологій, обмежуся звичним shell provisioning. Ну і в якості типової задачі – встановлення веб-сервера.

#!/usr/bin/env bash

sudo apt-get update
sudo apt-get install -y apache2
sudo rm /var/www/html/index.html -f
sudo mv /home/ubuntu/index.html /var/www/html/index.html

Тут все зовсім просто – оновлюємо систему, встановлюємо apache, видаляємо дефолтну сторінку, копіюємо свою наперед підготовлену сторінку, яку ми завантажили через file-provisioner.

Build

  packer build -var-file=variables.json template.json

Результат виконання білда:

==> Builds finished. The artifacts of successful builds are:
--> amazon-ebs: AMIs were created:

us-west-2: ami-bxxxxx85

Запускаємо ec2-інстанс з AMI, створеного через Packer – і маємо робочий сайт.

А тепер, власне, для чого так ускладнювати. Наприклад, ви, як девелопер, хочете працювати з таким же середовищем, яке запущено у production. Додаємо конфігурацію для Virtualbox provisioner-а. Додаємо один рядок конфігурації в постпроцесинг – і маємо робоче середовище. Особливо легко це робити з ще одним продуктом HashiCorp – Vagrant.

Preseeding
Єдина складність процесу інсталяції з iso – це preseeding – виконання інсталяції з використанням файлу конфігурації емуляції вибору параметрів сервера. Це не надто складна тема, якщо ви раніше вже мали досвід виконання таких інсталяцій. Коротко – в офіційній документації.
Нижче приводжу свій файл preseed.cfg:

## Options to set on the command line
d-i debian-installer/locale string en_US.utf8
d-i console-setup/ask_detect boolean false
d-i console-setup/layout string us

d-i netcfg/get_hostname string this-host
d-i netcfg/get_domain string this-host

d-i time/zone string UTC
d-i clock-setup/utc-auto boolean true
d-i clock-setup/utc boolean true

d-i kbd-chooser/method select American English

d-i base-installer/kernel/override-image string linux-server

d-i debconf debconf/frontend select Noninteractive

d-i pkgsel/install-language-support boolean false
tasksel tasksel/first multiselect standard, ubuntu-server

d-i partman-auto/method string regular
d-i partman-auto/purge_lvm_from_device boolean true
d-i partman-lvm/confirm boolean true
d-i partman-auto/choose_recipe select atomic
d-i partman/confirm_write_new_label boolean true
d-i partman/choose_partition select finish
d-i partman/confirm boolean true

# Default user
d-i passwd/user-fullname string ubuntu
d-i passwd/username string ubuntu
d-i passwd/user-password password ubuntu
d-i passwd/user-password-again password ubuntu
d-i user-setup/encrypt-home boolean false
d-i user-setup/allow-password-weak boolean true

# Minimum packages (see postinstall.sh)
d-i pkgsel/include string openssh-server ntp

# Upgrade packages after debootstrap? (none, safe-upgrade, full-upgrade)
# (note: set to none for speed)
d-i pkgsel/upgrade select none

d-i grub-installer/only_debian boolean true
d-i grub-installer/with_other_os boolean true
d-i finish-install/reboot_in_progress note

d-i pkgsel/update-policy select none

choose-mirror-bin mirror/http/proxy string

Щоб доставити його до гостьової машини знадобиться якийсь веб-сервер. Для Windows раджу mongoose – один бінарник, мінімум налаштувань. Запускайте його в каталозі з вашим файлом preseed.cfg і отримуєте веб-сервер на localhost-і. Після цього додаєте в termplater-vars ip-адресу вашого virtualbox-інтерфейсу та дефолтний порт 8080 – і ваша конфігурація буде підхоплена в preseeding процедуру.

Фінальна конфігурація шаблону має такий вигляд:

{
  "builders": [{
    "type": "amazon-ebs",
    "access_key": "{{user `aws_access_key`}}",
    "secret_key": "{{user `aws_secret_key`}}",
    "region": "{{user `aws_region`}}",
    "source_ami": "{{user `source_ami`}}",
    "instance_type": "{{user `instance_type`}}",
    "security_group_id": "{{user `security_group_id`}}",    
    "ssh_username": "{{user `ssh_username`}}",
    "tags": {
      "OS_Version": "Ubuntu 14.04"
    },
    "ami_name": "{{user `ami_name`}} [{{timestamp}}]",
    "ami_description": "Test build for itblogger post about packer"
  },
    {
  "type": "virtualbox-iso",
  "guest_os_type": "Ubuntu_64",
  "iso_url": "http://releases.ubuntu.com/14.04.3/ubuntu-14.04.3-server-amd64.iso",
  "iso_checksum": "9e5fecc94b3925bededed0fdca1bd417",
  "iso_checksum_type": "md5",
  "ssh_username": "{{user `ssh_username`}}",
  "ssh_password": "{{user `user_pass`}}",
  "shutdown_command": "echo '{{user `user_pass`}}' | sudo -S shutdown -P now",
   "boot_command" : [
            "<esc><esc><enter><wait>",
            "/install/vmlinuz noapic ",
            "preseed/url=http://{{user `web_server_ip`}}:{{user `web_server_port`}}/preseed.cfg ",
            "debian-installer=en_US auto locale=en_US kbd-chooser/method=us ",
            "hostname={{user `hostname`}} ",
            "fb=false debconf/frontend=noninteractive ",
            "keyboard-configuration/modelcode=SKIP keyboard-configuration/layout=USA ",
            "keyboard-configuration/variant=USA console-setup/ask_detect=false ",
            "initrd=/install/initrd.gz -- <enter><wait>"
        ]
    }
  ],
  "provisioners": [
      {
      "type": "file",
      "source": "index.html",
      "destination": "/home/{{user `ssh_username`}}/index.html"
    },
    { 
      "type": "shell",
      "script": "bootstrap.sh",
      "override": {
        "amazon-ebs": {
          "execute_command": "echo {{user `user_pass`}}  | sudo -S sh '{{ .Path }}'"
        }
      }
    }
  ],
  "post-processors": ["vagrant"]
}

Серед артефактів, окрім AMI, тепер в нас є і packer_amazon-ebs_aws.box та packer_amazon-ebs_virtualbox-iso.box файли, який можна імпортувати у vagrant.

vagrant box add amazon_box packer_amazon-ebs_aws.box

Отже, у нас є єдина конфігурація віртуальної машини, з якої можна отримати робочий ami образ для AWS та віртуальну машину для локальної роботи. Потрібно більше провайдерів – конфігуруєте свої provisioner-и та отримуєте той же результат на потрібній вам хмарній платформі.

На цьому завершую. Це лише перша частина матеріалу. Тепер, коли ви знайомі з інструментом Packer – можна переходити до хмарних мультиплатформенних архітектур сервісів, організацію яких забезпечує Terraform. Про це і розповім наступного разу.

Статті по темі: Vagrant

Настрій такий в останні місяці був дивний, що багато книжок прочиталося і багато віршів написалося. Мої незнайому друзі в соціальних мережах могли б, навіть, подумати, що я зовсім не інженер з технічною освітою, а якийсь філолог (нічого особистого, я люблю філологів). Тож я таки зібрався з думками і вирішив зробити допис і на технічну тематику. А так як основним трендом DevOps-року, що минає, були контейнери та Docker зокрема – про них і говоритиму.

Я і подумати не міг, що невеличка пауза в дослідженні около-докерівської тематики так далеко відкине мене від ситуації. Тому знадобилося багато часу, аби скласти всі пазли в одну картину і зрозуміти таки, що відбувається на цьому ринку. Власне, про сам Docker я вже писав і ще писатиму в новому році, але сьогодні мова про трохи вищий рівень абстракції – платформи для управління розгортанням, підтримки та моніторингу цих самих Docker-контейнерів.

Отже, окрім CoreOS на арену вийшли також гіганти дистрибуції linux-based операційних систем – Ubuntu та RedHat відповідно з проектами Ubuntu Core Snappy та Atomic. Здавалося б, з CoreOS все зрозуміло, але останні рішення щодо зміни стратегії розвитку свого продукту, прийняті в керівництві CoreOS сплутали дуже багато карт. Мова іде про Rocket – альтернативний до Docker варіант контейнерів.

Rocket

Звинувачувати CoreOS складно – якщо б не вони – це зробив би хтось інший. Не тільки тому, що всі хочуть на чомусь заробляти. Але тому, що Docker має свої суттєві недоліки і поява продукту, який буде намагатися усунути ці недоліки – було лише питанням часу. Взяти, хоча б, до уваги той пункт, що всі контейнери Docker централізовано працюють через єдиний демон. Але це помилка концептуальна. Її не поправиш патчем чи оновленням модуля. Переписувати весь проект з нуля?

Отже, CoreOS запустили open-source проект Rocket для менеджменту своїх App Containers (так в CoreOS називають Docker-контейнери). І основна причина такого кроку – це невідповідність шляху розвитку Docker-контейнерів очікуванням комюніті. Адже замість вдосконалення Docker-а як технології віртуалізації, Docker Inc. почали розробляти інтрументи для розгортання хмарних сервісів, кластерних систем, приватних репозиторіїв контейнерів. І все це зібрано та упаковано в один великий бінарник, який запускається з-під root-користувача… Погодьтеся – не надто привабливий програмний дизайн.

Що пропонує Rocket? По більшій мірі все те ж, але… Всі допоміжні утиліти для збирання, встановлення та шейрінгу контейнерів мусять бути незалежними від системи, хоч і тісно інтегруватися з нею. Разом з тим, протокол дистрибуції контейнерів не має бути при’язаним до платформи, як це є у випадку Docker. А сам формат контейнерів повинен обговорюватись та змінюватись під впливом ком’юніті, що дозволить таким чином зійтися на якомусь відкритому стандарті. За рахунок зміни моделі виконання Rocket розділяє архітектуру на етапи конфігурування середовища, файлової системи та, власне запуску застосунку в контейнері. Саме таким шляхом, на думку CEO CoreOS Алекса Полві, мав іти Docker. Але ж якби проблема полягала лише у погодженні цих двох приблуд – Docker та Rocket… Після ініціативи CoreOS, про свої наміри відцапати шматочок приватних клаудів на контейнерах заявили і Ubuntu з RedHat.

Ubuntu Core Snappy

За слова Шатлворта (начальник Ubuntu) – випуск Snappy – одна з найважливіших подій за 20 років існування Canonical. Ця редакція має дуже полегшене ядро. Власне, таке tiny-ядро існує вже декілька років і знайшло широке використання в embedded-системах. Але ця редакція цілком і повністю оптимізована для запуску Docker-ів та інших контейнерних технологій. Better, quicker, greater. Майже, як в популярній пісні. Core Snappy покликана вирішити, в першу чергу, проблему досттавки та оновлення застосунків в хмару, забезпечуючи належний рівень безпеки цих процесів. Все те ж, що і в CoreOS.

Серед інших особливостей Snappy – система безпеки AppArmor, яка вперше була представлена з мобільною версією Ubuntu. ОСобливість цієї система – повна ізольованість застосінків один від одного. Така архітектура забезпечить спокійний сон адміністраторам та девопс-ам, які захочуть встановлювати застосунки з нестабільних віток та неавторизованих джерел.

Якщо ж ваша параноя має левел вище 80-ого, то в ційє ОС ще одна особливість – транзакційні оновлення. Snappy має новий менеджер пакетів з одноіменною назвою. Тобто, тепер, замість apt-get update ви використовуватимете snappy update, який автоматично робитиме контрольну точку для відновлення при помилковому оновленні чи встановленні окремих пакетів.

Щодо менеджменту контейнерами, то Ubuntu Core Snappy має також свій гіпервізор для контейнерів – LXD. І з цим вищеперечисленим набором користувачі мають змогу погратися на Microsoft Azure, Amazon EC2 або Google Compute Engine. Digital Ocean поки не підтримує цієї операційної системи, тому я скористався останньою можливою опцією – запуск образа на локальній машині через KVM. Можливо, коли Snappy набере достатніх оборотів, я присвячу цій платформі трохи більше часу.

Red Hat Atomic

Покращена продуктивність, масштабованість та безпеки для розгортання та запуску ваших контейнерів – ось там описують проект Atomic Host в RHEL. Хм… Вам нічого не нагадує така характеристика продукту?

Як і Snappy, Atomic має оновлену систему управління пакетами, яка заснована на rpm-ostree. За концепцією цієї системи, всі оновлення компонуються в атомарні дерева, які можуть бути завантажені та встановлені “одним кроком”. Ця атомарність операції оновлення дозволяє з релгкістю повертати систему в попередній стан при виникненні помилок після оновлення.

А ось з процесом менеджменту контейнерами (модне слово – orchestration) RHEL теж не відстають. Atomic використовує проект Google – Kubernetes. Ця система включає інтструменти для горизонтального масштабування, мульти-контейнерне розгортання застосунків і, навіть, організацію багатошарових стеків із взаємопов’язаних кластерів контейнерів.

Серед інших плюшок – Cockpit – новий застосунок для адміністрування серверів через браузер. Серед підтримуваних опцій – і диски, і сервіси і журнали – все в браузері. Особлива увага – функції моніторингу та управління ресурсами контейнерів (процесор, пам’ять), стартування, зупинка, видалення та оновлення контейнерів.

Як і годиться для Enterprise-продукту, Atomic Host можна розгорнути не лише на Google Cloud Compute Engine чи Amazon EC2, але і на популярному інструменті для створення приватних хмар – VmWare VSPhere. Само собою, якщо ви звикли до стеку продуктів Red Hat – то Atomic підтримується і в Red Hat Enterprise Virtualization і Red Hat Enterprise Linux OpenStack Platform.

Що далі?

Підбиваючи підсумки хочеться сказати, що конкуренція – це завжди добре. Як і співпраця. Тому, надіюся, що розробники CoreOS, Ubuntu Core Snappy та RHEL Atomic Host разом з Docker прийдуть до спільного вирішення проблеми поділу ринку. Адже очевидно, що в 2015-у легкі  атомарні оновлення з дотриманням всіх стандартів безпеки гратимуть дуже важливу роль в розвитку як хмар великих провайдерів, так і приватних інфраструктур, побудованих з використанням переваг контейнерів і Docker-а зокрема.

Всім привіт. Я пам’ятаю, обіцяв наступним матеріалом писати про системи конфігурацій, але … Як завжди, але, бо ця тема справді дуже велика. Імовірно, кожному з менеджерів конфігурацій я приділю окремий матеріал. Тож, аби не відходити далеко від каси, сьогодні мова знову ітиме частково про Docker-контейнери і, зокрема, про добре масштабовану, безпечну та автоматизовану платформу для розгортання цих контейнерів.

Немає нічого дивного в тому, що із ростом популярності контейнерної віртуалізації, знайшлися люди, яких не задовільняло використання “важких” дистрибутивів Ubuntu Server, CentOS та інших. Використання для означення цих дистрибутивів слова “важких” – це про велику кількість зайвих компонентів та відсутність з коробки потрібних пакетів. Звісно ж, це ніяк не обмежує можливість налаштування і цих платформ як бази для розгортання контейнерів, але це марна трата ресурсів та часу на приведення платформи до потрібного стану.

Всі ці проблеми вирішує CoreOS. Це дуже легковісна операційна система (114 MB RAM) на базі ядра Linux, форкнута з ChromeOS. Головна фішка цієї системи – ізольованість кожного пакету в своєму контейнері. Навіть, не пакету, а, швидше, повноцінних застосунків, адже система не має пакетного менеджера. Кожен процес – Docker-контейнер як абстракція вищого рівня над LXC, що в свою чергу є абстракцією над низькорівневими cgroups.

Дизайн CoreOS передбачає значне спрощення розгортання вашого застосунку в кластері з контейнерів. Для представлення кластера як розподіленої системи, CoreOS використовує fleet – компонент, який інтегрує між собою systemd та etcd.

systemd – досить молода, але, вже зараз одна з найпопулярніших систем ініціалізації та керування статусом запущених в системі сервісів. В рамках CoreOS під процесами ми, фактично, маємо на увазі Docker-контейнери, всередині яких запускаються всі сервіси. Хоча, на низькому рівні це ніяк не змінює факту використання традиційного концепту юнітів та таргетів. Unit – це опис вашого контейнера, target – механізм групування різних юнітів одночасно. Вам цей концепт може бути знайомим на прикладі одночасного запуску процесів на різних runlevel-ах.

etcd – key-value storage, який використовується для збереження та обміну інформацією про сесії, кеш та багато інших параметрів конфігурації контейнерів. etcd встановлений на кожному контейнері. Обмін даними між вузлами здійснюється з допомогою протоколу Raft, а запис читання – по http/json через мережевий інтерфейс контейнера docker0. Якщо говорити про etcd, то для пояснення доцільності використання цієї key/value бази варто згадати його популярний аналог ZooKeeper від Apache Software Foundation. В чому, власне, особливість цих систем – їхня строга лінійна впорядкованість. Якщо піти трохи далі – то згадаємо і CAP-теорему Брюера, згідно якої в системах розподілених обчислень одночасно можливо реалізувати лише дві з трьох властивостей: consistency(у всіх вузлах дані синхронізовані), availability(доступність в будь-який момент часу), partition tolerance(розбивання на ноди не веде до повертання некоректних даних при запиті). В результаті цієї теореми, key/value стореджі розбиваються на три класи: CA, AP та CP.

Отже, etcd відноситься до класу CP, що відповідає ситуації, коли ваша розподілена система не завжди може відповідати на запити, але гарантує строгу консистетність даних на всіх вузлах.

Реалізується ця консистентність протоколом Raft за рахунок вибору master-вузла та розподілених lock-ів. ОСь тут є дуже хороша презентація по протоколу Raft.

Власне, тут мав іти приклад розгортання якогось кластера на базі CoreOS, але сайт проекту має на стільки хорошу документацію, що не бачу сенсу дублювати інформацію. Так, все вище описане – теж дублювання, але мета цього разу була інша – хотів донести до вас інформацію про існування такої штуки. Тим паче, на сьогодні офіційна підтримка CoreOS вже є в Amazon Ec2, Rackspace, Google Compute Engine та моєму улюбленому DigitalOcean. Або ж встановити на голе залізо, чи, навіть завантажитись через PXE. Якщо ж ви бажаєте погратися вже тут і зараз – опцію розгортання через Vagrant теж ніхто не відміняв. Всього доброго!

Тобто, перелічена типи віртуалізації використовуються на рівні операційної системи. Якщо вам цікаво спуститися на рівень нижче – тоді вам до cgroups, на базі яких працює LXC. Ось тут є гарний відеоматеріл з Яндекса по cgroup-ах . Зверніть увагу – LXC працює лише на хостовій платформі з ОС Linux. Переваги LXC – як і в будь-якій контейнерній віртуалізації – швидкість розгортання, нативна швидкодія. Наприклад, розгортання нового віртуального оточення з боксу Vagrant займає близько 30 секунд часу. Перезавантаження – 10-15 секунд. Щодо недоліків – то, власне, використання уніфікованого ядра може бути як перевагою так і недоліком.

LXC

Надто багато я розписую. Як каже мій колега – “все це можна знайти в інтернеті і нікому непотрібно”. Стаття не про LXC, а про використання його та інших інструментів із Vagrant. Тому, аби зберегти свій час – перейду до плагіна.

Для початку встановимо LXC, якщо ви ще не зробили цього.

sudo apt-get install lxc

Я міг би запропонувати вам знову ж www.vagrantbox.es для пошуку потрібного нам бокса. Але там більшість боксів для старішої версії LXC. Тому, раджу ресурс vagrantcloud.com, де можна взяти бокс від автора плагіна vagrant-lxc. Його назва – fgrehm/raring64-lxc. Створимо новий каталог та ініціалізуємо Vagrant-box:

mkdir test-lxc
 cd text-lxc/
vagrant init fgrehm/precise64-lxc

Щодо конфігурації Vagrantfile – то тут все аналогічно, за винятком, що в провайдері поки не працює config.vm.network. Тобто, брідж-мережу зробити вам не вийде. Та і для форвардингу використовується redir, бо реалізація iptables на різних дистрибутивах по-різному не дозволяє використовувати iptables для прокидання портів. Перед підняттям машинки залишається лише встановити плагін vagrant-lxc. Гадаю, ви вже використовуєте Vagrant версії 1.5+, тому встановлення плагіна виглядає трохи незвично:

vagrant plugin install vagrant-lxc --plugin-version 1.0.0.alpha.2

Ну і, запуск VE:

vagrant up --provider=lxc

Будьте готові до того, що команда вимагає дуже багато введень пароля на root-доступ. Це пов’язано з відсутністю підтримки UserNamespaces на рівня ядра. Тому у Vagrant є спеціальна команда: vagrant lxc sudoers, яка створить скрипт із всіма командами, потрібними для роботи плагіна. Зробіть його виконуваним та запустіть – тепер вам не треба десятки разів вводити пароль.

chmod a+x lxc-sudoers.sh
sudo ./lxc-sudoers.sh

Перевіряємо через команду “sudo lxc-list” аби пересвідчитись, що все працює як треба. До речі, я тут про cgroup-и згадував. Так от, через cgroups можна керувати ресурсами lxc-контейнера прямо з конфігурації Vagrantbox. Наприклад, змінити ліміт оперативки:

Vagrant.configure("2") do |config|
 config.vm.box = "precise64-lxc"
 config.vm.provider :lxc do |lxc|
 # Те ж, що і 'customize ["modifyvm", :id, "--memory", "1024"]' для VirtualBox
 lxc.customize 'cgroup.memory.limit_in_bytes', '1024M'
 end

Треба відзначити, що на момент написання цього матеріалу – lxc-плагін для версії Vagrant 1.5+ працює не надто стабільно, але автор щоденно здійснює комміти на github з виправленням, тому, гадаю, найближчим часом плагін вийде вже у версії beta.

AMAZON AWS

Власне, можна багато говорити про інші провайдери, але суть залишається та ж сама – шукаєте плагін тут , встановлюєте його через sudo apt-get install %PLUGIN_NAME% і тестуєте. Для вправляння у конфігурації Vagrantfile раджу глянути на libvirt-плагін. Сам по собі libvirt як інструмент керування гіпервізорами має дуже багато налаштувань для роботи з віртуальними ресурсами пам’яті, диска, процесора, мережі. Тому його конфігурація як провайдера для віртуальних оточень через Vagrant має багато особливостей.  Щодо інших провайдерів… Тут впевненим на 100% бути складно, адже плагіни розробляються по більшій мірі – як open-source проекти. Часто оновлюються, вилітають при оновлення версій гіпервізорів, змін в ядрі і т.д. Звісно ж, є комерційні рішення, як от плагін для VMware Fusion та Workstation від Hashi Corp (компанія Хашимото – автора Vagrant). Але коштують вони 75$ за інстанс Vagrant. Тому, варто поговорити трохи про ті провайдери, які зараз дуже популярні в користувачів та причини цієї популярності.

Мова, звісно ж, іде про хмари та контейнерну віртуалізацію, як наслідок. І тут я пробіжуся по підготовці образів для розгортання в Amazon Web Services та DigitalOcean.

AWS

Встановлюємо плагін:

vagrant plugin install vagrant-aws

Зверніть увагу, що на цьому етапі – у вас вже мають бути актуалізовані дані в профілі AWS, зокрема публічні ключі для створення інстансу та доступу по ssh (EC2), та спеціальні ключі від AWS. Додаємо новий бокс (використовується ubuntu від автора плагіна) та ініціалізуємо Vagrantfile:

vagrant box add itblogger-aws https://github.com/mitchellh/vagrant-aws/raw/master/dummy.box
vagrant init itblogger-aws

Далі відкриваємо в улюбленому редакторі Vagrantfile і додаємо наступний блок конфігурації (ключі, звісно, замінені):

config.vm.provider :aws do |aws, override|
 aws.access_key_id = "ASFHGJGDDFG3Q24YDQ"
 aws.secret_access_key = "M1ByoSDHGJG+9JKiblGFHJSF9Ro8u3tZ"
 aws.keypair_name = "itblogger-aws"

aws.ami = "ami-7747d01e"

 override.ssh.username = "ubuntu"
 override.ssh.private_key_path = "itblogger-aws.pem"

 aws.security_groups = [ 'core_access' ]

 aws.tags = {
 'site' => 'itblogger.org.ua',
 }
 end

Ця конфігурація базується на тій, яка приведена на сторінці автора плагіну на github за винятком двох параметрів. Першй з них – це aws.security_groups. Цей параметр дозволяє встановити параметри безпеки, згідно якими можна обмежити роботу деяких мережевих протоколів. За замовчуванням AWS EC2 має security group з іменем “default”, в якій дозволені всі протоколи. І саме цю групу використовує плагін vagrant-aws для підключення до інстансу по ssh після його розгортання. Але після двох спроб розгорнути новий інстанс – процес зависав на перевірці ssh-підключення для запуску rsync (використовується для шейру локальної директорії з /vagrant директорією інстансу). Як виявилося – це якийсь баг в плагіні. Інстанси створюються і їх можна бачити в консолі EC2, але локальна консоль висить на перевірці ssh. Треба баг-репорт зробити. Для того, аби виправити цю помилку – створіть нову security group і через параметр aws.security_groups задайте її у Vagrantfile.

Другий параметр – aws.tags ніяк функціонально не впливає на роботу інстансу, але без нього процес розгортання також обривався. Отже, запускаємо:

vagrant up --provider=aws

Чекаємо хвилинку і отримуємо результат:

==> default: Launching an instance with the following settings...
==> default: -- Type: m1.small
==> default: -- AMI: ami-7747d01e
==> default: -- Region: us-east-1
==> default: -- Keypair: itblogger-aws
==> default: -- Security Groups: ["core_access"]
==> default: -- Block Device Mapping: []
==> default: -- Terminate On Shutdown: false
==> default: -- Monitoring: false
==> default: -- EBS optimized: false
==> default: -- Assigning a public IP address in a VPC: false
==> default: Waiting for instance to become "ready"...
==> default: Waiting for SSH to become available...
==> default: Machine is booted and ready for use!
==> default: Rsyncing folder: /home/core/Dropbox/Projects/DevOps/Vagrant/itblogger-aws/ => /vagrant

Перевіряємо статус:

vagrant box list
fgrehm/precise64-lxc (lxc, 1.1.0)
itblogger-aws (aws, 0)

В EC2 консолі:

Чудово. Отже, для розгортання ваших боксів плагін чудово підійде. Щодо налаштування інстансу – інтеграція з Chef через ssh-сесію також працює без проблем. Але до цього питання ми ще повернемося, коли говоритимемо про систему управління конфігураціями.

Ліричний відступ

Протягом цих розгортань готових боксів – у вас могло виникнути логічне питання – а як же свій приготувати? Про це я розповім пізніше, але якщо ви хочете почати створювати власні бокси вже зараз – інструмент Packer від автора Vagrant – те, що вам потрібно. Він дозволяє готувати і Docker-образи, і AMI для AMS і багато-багато іншого.

DIGITALOCEAN

DigitalOcean – Мій улюблений VPS провайдер. Завдяки низьким цінам (5$ за місяць за інстанс з 512Ram та 2GB диску) та хорошій швидкодії завдяки SSD-дискам – популярність цього сервісу росте шаленими темпами, незважаючи на суттєві проблеми із стабільністю роботи зон. Але, на жаль, саме зараз, тимчасово, можливості ппрацювати з DigitalOcean у Vagrant немає, оскільки перші оновили API до версії 2.0 і авторизація тепер працює на токенах (oAuth), а от плагін досі використовує API версії 1.0, який для авторизації використовував cliend_id та private_key параметри, що тепер недоступні. Автор вже працює над оновленням плагіну, але термінів реалізації поки немає. Деталі тут .

DOCKER

Переходимо до останнього розділу. Імовірно, Docker заслуговує окремого матеріалу, але … Чесно сказати, я не розділяю всього цього шуму навколо чергових Linux-контейнерів. Взагалі, як було відзначено раніше, популяризація хмар – одна з основних причин розростання моди на контейнери. Але у випадку з Docker – тут є ще деякі фактори, які можна виділити в процесі стрімкого зростання кількості згадувань його в мережі. Зокрема, це використання LXC як низькорівневої віртуалізації, для якої Docker – лише вищий рівень абстракції, що дуже спрощує ізоляцію процесів та їхню роботу з пам’яттю, процесором та диском. Ще один плюс в сторону “модності” – Docker написаний на Go, що за швидкодією рівняється до нативних програм, написаних на С, але без проблем контролю пам’яті (за рахунок вбудованого garbage collector-а). Ну і ще один, не менш важливий пункт, який ми поки не можемо оцінити по достоїнству – інтеграція із системами контролю конфігурацій – Puppet, Salt, Chef, Ansiblе. І, щоб ви не думали, що Docker це якась хіпстерська фігня – підтримка цих контейнерів вже є і в Amazon, і в Rackspace, і в Microsoft Azure, і в IBM SoftLayer, і в Google Compute Engine.

За час тестування Docker-а – у всяких мануалах я зустрічав багато різних тверджень про Docker, які не мають нічого спільного з реальністю. Тому, перед тим, як перейти до вирішення якоїсь реальної задачі, декілька слів про за і проти.
Чим Docker може бути?
1. Інструмент доставки та розгортання образів (distribution & deploy) завдяки тісній інтеграцій ї менеджерами конфігурацій.
2. Менеджер віртуальної інфраструктури. Це зараз Docker – надбудова на Linux Containers. Але ніхто не відкидає імовірність появи таких же надбудов над KVM чи Hyper-V.
3. Віртуальна лабораторія з можливістю трекінгу різних версій вашого ПЗ (саме ПЗ, а не коду). Docker використовує btrfs (copy-on-write filesystem), що дозволяє відслідковувати зміни в образах через diff-like команди (чи, як в git status, якщо вам така аналогія рідніша).

Підсумовуючи – мені подобається аналогія Docker-а з мовою програмування Java. Write once – run everywhere. Теж саме і тут – сконфігуруй раз – і запускай будь-те із впевненістю, що працюватиме ваш контейнер так само. Звісно, enterprise-девелопери заперечать мені, натякаючи на мільйони залежностей від баз даних/черг/балансерів і т.д. Але це все питання рівності рук і бажання автоматизувати рутину. І лише на 20% – готовності продукту до впровадження в production-системи.

А тепер – про реальні задачі. Встановлення Docker описано тут  для різних платформ. Є два шляхи підняття VE -на базі власноруч написаного Dockerfile, або ж із використанням готового образу, взятого з Docker Index. (аналог Amazon AMI Mаrketplace). Другий варіант чудово працює для запуску VE одразу через docker, але з vagrant такий метод вимагає використання великої кількості додаткових команд у Vagrantfile. Тому зручніше використовувати директиву build_dir = “. ” та Dockerfile (інтерактивний туторіал – hwww.docker.com/tryit.

Ця тема присвячена провайдерам, але, оскільки зараз в мене є доступ лише до ОС Windows як host-системи, то я використовуватиму Docker як provisioner. Воно і добре – буде легенький вступ до наступного матеріалу. Тим більше, рідко хто використовує Docker саме як provider, а не provisioner. В чому різниця? Provider здійснює запуск готового образу, provisioner – виконує набір команд для налаштування вашого контейнера. Наприклад, автоматичне оновлення при запуску. Про provisioning ми поговоримо детально в наступному матеріалі, а для прикладу зараз я використаю Docker в якості provisioner-а для контейнера, запущеного через Vagrant з допомогою провайдера Virtualbox.

Наприклад, для запуску nginx-сервера. Vagrantfile:

VAGRANTFILE_API_VERSION = "2"

Vagrant.configure(VAGRANTFILE_API_VERSION) do |config|
 # All Vagrant configuration is done here. The most common configuration
 # options are documented and commented below. For a complete reference,
 # please see the online documentation at vagrantup.com.

# Every Vagrant virtual environment requires a box to build off of.
 config.vm.box = "docker"
 config.vm.box_url = "https://oss-binaries.phusionpassenger.com/vagrant/boxes/latest/ubuntu-14.04-amd64-vbox.box"

#provision починається після старту віртуальної машин.
 #Тут - на основі Dockerfile виконується збирання образу і потім його запуск.
 config.vm.provision "docker" do |docker|
 docker.build_image "/vagrant/nginx", args: "-t nginx"
 docker.run "nginx"
 end

#Прокидання портів до контейнера
 config.vm.network "forwarded_port", guest: 80, host: 80
 config.vm.network "forwarded_port", guest: 443, host: 443
 end

Dockerfile, на основі якого відбувається збирання контейнера взятий тут . Його потрібно покласти в папку nginx(як вказано у конфігурації вище):

#
# Nginx Dockerfile
#
# https://github.com/dockerfile/nginx
#

# Pull base image.
FROM dockerfile/ubuntu

# Install Nginx.
RUN \
 add-apt-repository -y ppa:nginx/stable && \
 apt-get update && \
 apt-get install -y nginx && \
 echo "\ndaemon off;" >> /etc/nginx/nginx.conf && \
 chown -R www-data:www-data /var/lib/nginx

# Define mountable directories.
VOLUME ["/data", "/etc/nginx/sites-enabled", "/var/log/nginx"]

# Define working directory.
WORKDIR /etc/nginx

# Define default command.
CMD ["nginx"]

# Expose ports.
EXPOSE 80
EXPOSE 443

Оскільки я додавав блок provisioning вже після створення віртуалки, то для його застосування потрібно перезавантажити virtualbox-машину та явно вказати директиву provision: vagrant reload –provision:
Результат:

==> default: Attempting graceful shutdown of VM...
==> default: Clearing any previously set forwarded ports...
==> default: Clearing any previously set network interfaces...
==> default: Preparing network interfaces based on configuration...
 default: Adapter 1: nat
==> default: You are trying to forward to privileged ports (ports <= 1024). Most ==> default: operating systems restrict this to only privileged process (typical
ly
==> default: processes running as an administrative user). This is a warning in
case
==> default: the port forwarding doesn't work. If any problems occur, please try
==> default: port higher than 1024.
==> default: Forwarding ports...
 default: 80 => 80 (adapter 1)
 default: 443 => 443 (adapter 1)
 default: 22 => 2222 (adapter 1)
==> default: Booting VM...
==> default: Waiting for machine to boot. This may take a few minutes...
 default: SSH address: 127.0.0.1:2222
 default: SSH username: vagrant
 default: SSH auth method: private key
 default: Warning: Connection timeout. Retrying...
==> default: Machine booted and ready!
==> default: Checking for guest additions in VM...
==> default: Mounting shared folders...
 default: /vagrant => E:/dropbox/Dropbox/Projects/DevOps/Vagrant/docker
==> default: Running provisioner: docker...
 default: Installing Docker (latest) onto machine...
 default: Configuring Docker to autostart containers...
==> default: Building Docker images...
==> default: -- Path: /vagrant/nginx
==> default: Starting Docker containers...
==> default: -- Container: nginx

Аби пересвічитись, що все пройшло як треба, зайдемо через ssh в наш box і перевіримо статус контейнера:

vagrant@ubuntu-14:~$ docker ps
CONTAINERID  IMAGE        COMMAND CREATED     STATUS         PORTS            NAMES
f64399f09210 nginx:latest nginx 56 seconds ago Up 55 seconds 443/tcp, 80/tcp nginx

Що ж, здається, все пройшло як треба. Щодо можливостей конфігруації в Dockerfile, то в наступному матеріалі я візьму якийсь ширший приклад із, скажімо, налаштуванням лінкування між контейнерами. Ну і в сторону більш складних систем конфігурацій гляну. А на сьогодні це все. Миру вам.

Привіт піпли. Від часу останнього матеріалу пройшло не так багато часу, але я вирішив не затягувати з оновленнями ще на декілька місяців. Як це часто буває, в процесі планування допису накопичилося дуже багато інформації, в результаті чого довелося трохи переформатувати початковий зміст. Як я і обіцяв у матеріалі про PaaS від IBM – Bluemix, наступною цілюю буде організація контейнерної віртуалізації без послуг хостера. Але це надто обширна тема, аби писати про неї одним дописом, тому я вирішив трохи розширити список технологій та продуктів для огляду, додавши сюди інші популярні провайдери VE (virtual environment), системи конфігурацій та менеджери віртуальних оточень. Аби тримати віртуальну лабораторію в порядку і не мусорити – почну саме з менеджера віртуальних оточень.

Для чого вам це? Логічне питання, яке постає перед використанням будь-яких технологій, що замінюють вже звичні процедури: відкрити Virtualbox, створити віртуалку, задати мільйон параметрів, змонтувати образ, встановити систему, налаштувати мережу і т.д. Так от, Vagrant цей процес дуже спрощує, замінюючи вищеописаний процес – одним box-файлом. Ну і, Virtualbox – це ж лише погратися, для тестів. А якщо, коли ми готуємо ПЗ для розгортання на якийсь продакшн з KVM, openvz чи Xen? Про це далі.

Рік тому, коли я краєм ока оглядав Vagrant – це був лише wrapper (обгортка) для VirtualBox-інстансів віртуальних машин. Але з часом комюніті активно почало дописувати свої плагіни для інших провайдерів віртуальних середовищ, тим самим популяризуючи Vagrant як передову систему менеджменту віртуальних оточень дла тестування та розгортання ПЗ. Особливу роль тут відіграли підтримка популярного в корпоративному сегменті VMWare та, Amazon AWS, послугами якого користуються більшість сучасних технологічних стартапів.

Наперед мушу вибачитись, якщо девелоперам не сподобається мій виклад матеріалу. Я розглядатиму всі інструменти як operations engineer (devops), тому, імовірно, деякі пункти можу пропустити. Отже, для початку поділимо все вище-перелічене на три категорії: Management, Providing і Provisioning. В такому ж порядку ітимуть і статті. Так от Management(управління) – це Vagrant, Providing (забезпечення, надання) – це VMWare VSphere, AWS, Virtualbox, Docker, Azure, DigitalOcean, KVM, libvirt, LXC, Rackspace, Hyper-V, OpenStack, Proxmox, Openvz та інші. Тобто, це технології віртуалізації або ж побудовані на їх основі інструменти розгортання нових інстансів віртуальних оточень. Ну і Provisioning – не впевнений, що переклад “постачання” підходить, але якщо вже так – тоді це постачання конфігурацій. Тобто, логіка описаного стеку наступна: менеджер Vagrant через одного з провайдерів створює новий VE (virtual environment) та, користуючись однією, або і декількома, системами конфігурацій(етап provisioning) – перевіряє стан віртуального оточення на відповідність до описаної конфігурації (cookbook в Chef, модулі в Puppet, playbook в Ansible чи state в Salt).

Ок, описувати процес інсталяції, звісно ж, не буду. Але що вам зараз треба зробити – так це піти і завантажити Vagrant віддповідно до вашої ОС. Зараз я використовую Vagrant на Windows 8 x64, хоча, надалі будуть приклади і на ОС з ядром Linux, тому, підготуйте і віртуалочку, якщо під рукою такої ОС немає. Ну і провайдер, за замовчуванням це Virtualbox, встановіть. Готово? Стартуємо cmd, створюємо новий каталог та ініціалізуємо новий box:

vagrant init

Ця команда генерує типовий конфігураційний файл Vagrantfile. Цей файл визначає всі необхідні параметри бокса (box – формат об’єкта, з яким працює Vagrant): ім’я базового образу, прокидувані порти, папки для синхронізації та інше. Про параметри Vagrantfile ми ще поговоримо пізніше.

Для створення нової віртуальної машини використовуються так звані base boxes. Зазвичай, це образ із мінімальним набором конфігурацій та ПЗ, якого достатньо для комунікації із системою. Подальше розгортання конфігурацій та програмного забезпечення покладається на provisioning-систему. Дуже зручний сайт для вибору базового образу – http://www.vagrantbox.es. Як бачите, окрім чистих систем на зразок Ubuntu precise 32 VirtualBox, на сайті розміщені і готові користувацькі образи із сконфігурованими provisioning-системами, чи LAMP-стеком, чи MEAN-стеком, системами моніторингу та ін. Звісно ж, ніхто не заважає вам у базовому образі тримати налаштовану конфігурацію і починати розгортання віртуального оточення вже із підготовленим ПЗ. Але тут ідея в тому, що конфігурація provisioning-системи значно менша, за образ, відповідно розливати нові конфігурації того ж Puppet-а чи Chef-а – менш-затратно по ресурсах, ніж розливати оновлені образи.

Отже, обрали базовий бокс – Ubuntu precise 64 VirtualBox – копіюємо (посилання із сайту www.vagrantbox.es) посилання і в консолі фігачимо:

vagrant box add base http://files.vagrantup.com/precise64.box

==> box: Adding box 'base' (v0) for provider:
    box: Downloading: http://files.vagrantup.com/precise64.box
    box: Progress: 100% (Rate: 1959k/s, Estimated time remaining: --:--:--)
==> box: Successfully added box 'base' (v0) for 'virtualbox'!

Спостерігаємо за процесом завантаження, допиваємо каву і стартуємо, нарешті, нашу машинку:

vagrant up

Повертаємося до Virtualbox-а – і бачимо нашу машинку вже в запущеному стані.

Ще один метод перевірки – vagrant status:

Current machine states:
default                   running (virtualbox)

З Virtualbox ніяких проблем виникати і не мало. Тепер, як я і обіцяв, повернемося до вмісту Vagrantfile. Це написана на Ruby конфігруація нашого VE, тому будьте обережні, аби не поламати синтаксис. За замовчуванням – більшість параметрів закоментовані. Серед того, що не закоментовано:

• VAGRANTFILE_API_VERSION = “2” – для нас це не надто актуально, адже параметр був введений для міграції з версії 1.1 до 2.0.
• config.vm.box = “base” – тут вказано ім’я базового боксу, який використовуватиметься для запуску віртуального оточення. Оскільки проект був ініціалізований без імені, то за замовчуванням в ім’я записується base, для якого ми наступною командою вказали адресу боксу. Цей процес можна дещо автоматизувати, вказавши адресу образу в параметрі config.vm.box_url. Цей параметр також називаютьсь fallback url і, зазвичай, він використовується при шейрінгу вашого боксу. Тобто, ви забиваєте fallback url з адресою вашого боксу в конфіг і тоді просто віддаєте конфіг файл Vagrantfile, з яким ваші колеги набравши vagrant init && vagrant up розгорнуть та запустять копію вашого інстансу.

Отже, наше середовище запущено, але як же з ним комунікувати? Якщо ви вже пробували запустити новий проект через Vagrant, то могли помітити, що під час стартування віртуалки логер видає такі рядки:

==> default: Preparing network interfaces based on configuration...
    default: Adapter 1: nat
==> default: Forwarding ports...
    default: 22 => 2222 (adapter 1)

Отже, мережа за замовчуванням прокинута через NAT і налаштований форвард порта для встановлення ssh сесії. Тому до віртуального середовища можна підключитися як через ssh на порт 2222 мережевого інтерфейсу host-системи, або ж через команду “vagrant ssh” в директорії проекту. Звісно ж, окрім параметрів за замовчуванням – у Vagrantfile можна налаштувати прокидання й інших портів. Зокрема, для веб-проектів це може бути http порт 80. Це робить через відповідний запис в конфігурації:

config.vm.network "forwarded_port", guest: 80, host: 8080

Ви можете і не прокидати портів, замінивши використання NAT на public(bridged) network:

config.vm.network "public_network"

або через private network:

config.vm.network :private_network, ip: "192.168.1.100".

Ну і останнє, що може ваш зацікавити – це шейр директорій. Як і у випадку з SSH, за замовчуванням кореневий каталог проекту на host-системі синхронізується із каталогом /vagrant в корені гостьової системи. Через Vagrantfile можна додати й інші папки для снхронізації:

config.vm.synced_folder "../data", "/vagrant_data"

де “../data” відповідно директорія host-системи, “/vagrant_data” – директорія guest-системи. Серед іншого – підтримка nfs.

Гадаю, на цьому місці ми зупинемося. Зберігаючи логічну послідовність – більш цікаві провайдери, на зразок Docker LXC та KVM – залишимо для наступного матеріалу. Ніби все, якщо забув щось – коментарі внизу.

Чому я взяв новачок у лапки? Ну, називати ІТ-гіганта IBM новачком хоч у чомусь – досить складно. Звісно, раніше це були суто внутрішні сервіси, але минулого року IBM придбали IAAS (infrastructure as a service) компанії SoftLayer і почали просуватися в напрямку до користувача. Та все ж,серед PааS (platform as a service) IBM – не конкурент іменитим Amazon AWS, Microsoft Azure чи Google App Engine. Навіть, опустимося нижче, де є Cloud Foundry від VMWare; Heroku, який починав як популярна хост-платформа для Ruby-додатків, але потім додав і Node.js, Scala, Closure, Python та інші; OpenShift від RedHat; і, навіть, мій улюблений Digital Ocean, який позиціонує себе як VPS, в першу чергу, але пропонує і автоматичне розгортання сервісів: MEAN (популярний стек із Mongo, Express, Angular, Node.js), традиційний LAMP, Django-фреймворк для Python, блогова платформа WordPress, Ruby on Rails, Docker чи менеджер проектів Redmine. Отже, знову, чому ж IBM? Справа в тому, що я вже от два роки маю практики роботи з таким продуктом від IBM як Domino і кожного дня доводиться чути багато поганих слів про цю платформу. Та і сам я не часто щось хороше про неї говорю. Після втрати IBM позицій на hardware-ринку серверного обладнання, хочеться вірити, що IBM, окрім потужної дослідницької команди, може робити якісний продукт у сфері хмарних обчислень.

IBM Bluemix знаходиться у стадії бета-тестування, але каталог додатків та сервісів вже містить досить широкий набір шаблонів, підготовлених як розробниками IBM, так і написаних членами комюніті. Ось так виглядає панель користувача Bluemix:

Досить приємно, хоча, і з великою кількістю порожніх місць, які в майбутньому будуть заповнені нашими додатками чи сервісами. Окрім цих опцій, Bluemix також пропонує add-ons (додатки) до сервісів та застосунків. Каталог шаблонів розбитий за функціональним принципом і містить аж 8 розділів. Розглянемо коротенько кожен із цих розділів:

1. Boilerplates (комплексні рішення) – це наймасштабніші темплейти на Bluemix, які включають в себе декілька окремих рішень, вже сконфігурованих для використання “з коробки”. Власне, ці рішення – це просто runtime+db. Тому, якщо якась із цих складових у вас вже є – ви можете скористатися  одним з окреми обраних хмарних сервісів.

1.1 Internet of Things – це тестовий набір для демонстрації платформи Bluemix, який включає в себе Node-Red (візуальний інструмент для побудови архітектури вашого застосунку. ), TimeSeriesDatabase та API
1.2 Java Web Starter – WebSphere Liberty java web-server + DataCache (покращення продуктивності баз даних, які лежать на повільних дисках).
1.3 Mobile Cloud – Node.js runtime + MAS (Mobile Application Security) + Push (для iOS та Android) + Mobile Data (scalable та managed DB сервіс)
1.4 Node.js web-starter – runtime + DataCache
1.5 Java + DB web-starter – runtime + SQL DB сервіс.

2. Runtimes – як ви вже зрозуміли, з попереднього розділу – IBM додала підтримку Java та Javasxript рантаймів з коробки. А от комюніті вже додали Rails та Sinatra оточення. Дивно, досі немає пітонівських Django та Flask. Дрімає комюніті пітоністів.

3. Add-Ons – доповнення до існуючих сервісів для управління та моніторингу.

3.1 Auto-Scaling – автоматичне розгортання новий інстансів для масштабування проекту при зростанні навантаження.
3.2 CloudIntegration – API для інтеграції вашої clоud-based з іншими системами.
3.3 Monitoring and Analytics – власне, моніторинг та аналітика доступності вашого сервісу, навантаження та ін.
3.4 RapidApps – візуальний білдер застосунків.

4. Web and Application – ІМХО, найцікавіший розділ. Поясню чому – всі описані вище темплейти орієнтовані на комплексне розгортання на платформі Bluemix. Звісно, це хороше рішення, тримати все у хмарі. Але, якщо, скажімо, якісь security policy вимагають від вас утримання даних на своїх серверах, а от масштабування веб-додатку вимагає розгортання в хмарі – ви можете скористатися якимось окремими сервісами, як от runtime та AMQP меседжинг-сервіс (RabbitMQ, ElasticMQ, наприклад). Окрім згаданих меседж-сервісів, тут вам і сервіс аналізу логів, і Rules-сервіс для закладання бізнес-логіки застосунків, SessionCache для зберігання інформації про сесії користувачів, MemCached та Redis сховища даних, email-сервіс SendGrid, Twilio для збірки додатків з VoIP та чат-системою для вашого веб- чи мобільного застосунку.

5. Mobile – компоненти цієї категорії загадні вище, тому зупинятися детальніше не буду.

6. Data Management – типові DBaaS (distributed database as a service) – Cloudant JSONDB, SQLDB (DB2), ClearDB Mysql, ElephantSQL (Postgre SQL) та, реалізовані комюніті, MongoDB, mysql та postgresql. На всі смаки.

7. Big Data – робота з великими об’ємами даних, для яких серед невідомих мені спеціалізованих рішень IBM є і традиційний Map/Reduce сервіс на базі Hadoop.

8. DevOps – сервіси для інженерів вашого стеку у хмарі. Тут і Git, і Web IDE, інтеграція з Eclipse та Visual Studio, load-тестування для перевірки стійкості вашого сервісу до навантаження.

Весь цей був би непотрібним, навіть, для мене, не кажу вже про можливих читачів (хоч хтось?), якби я не спробував запустити якийсь демо проект для наглядності. Звісно, в мене немає, ніяких застосунків, які потребують масштабування у хмарі, тому я розгорну якийсь демо-проект.

Ось я за хвилинку накидав: веб-сервер на базі Node.js, який буде запускати наш застосунок, а, отже, розміщується в розділі APPS. Також я додав сервіс MongoDB, який в один клік кріпиться до нашого Node.js рантайму, DevOps сервіс, доповнення поніторингу та аналізу (меню Add-Ons зліва), сервіс автоматичного масштабування та незалежний сервіс Load Impact. Після додавання нового сервісу – віртуальне оточення потрібно перезавантажити, аби Manifest-конфігурація із внесеними поправками була зчитана повторно.  Сервіси дуже просто прикліплювати до вашого проекту:

В панелі керування можна бачити кількість запущених сервісів, використовувану пам’ять та доступність ваших застосунків.

Після запуску застосунку – він одразу доступний за адресою в домені, наданим системою. Звісно ж, передбачена можливість прикріплення свого доменного імені.

Всі сервіси конфігуруються через Manifest-файл з json-форматом конфігурацій, який містить багато системних змінних, як от, наприклад,  VCAP_SERVICES, де зберігається інформація про прикліплені сервіси. Доступні також User-Defined змінні оточення для задавання змінних, не пов’язаних із сервісами, а які відносяться суто до вашого інстансу із додатком.

DevOps сервіс дозволяє автоматизувати створення git-репозиторію з розміщенням хабу на hub.jazz.net. Там вам пропонується і Web IDE для спільної роботи над проектом. Я залив проект, який використовує Express.js поверх Node.js в якості веб-фреймворку та Jade як template-engine. App.js за замовчуванням парсить Manifest-файл із всіма опціями, які нагенерував Bluemix та вписав сам користувач і, стартує наш веб-апп.

// VCAP_APPLICATION contains useful information about a deployed application.
var appInfo = JSON.parse(process.env.VCAP_APPLICATION || "{}");
// TODO: Get application information and use it in your app.
// VCAP_SERVICES contains all the credentials of services bound to
// this application. For details of its content, please refer to
// the document or sample of each service.
var services = JSON.parse(process.env.VCAP_SERVICES || "{}");
// TODO: Get service credentials and communicate with bluemix services.
// The IP address of the Cloud Foundry DEA (Droplet Execution Agent) that hosts this application:
var host = (process.env.VCAP_APP_HOST || 'localhost');
// The port on the DEA for communication with the application:
var port = (process.env.VCAP_APP_PORT || 3000);
// Start server
app.listen(port, host);
console.log('App started on port ' + port);

Звісно ж, вас ніхто не заставляє використовувати Web IDE. Хоча, вона досить мила.

Ви можете клонувати репозиторій на локальну машину, вносити свої правки, пушити зміни на віддалений репозиторій і вже з панелі роботи над проектом виконувати розгортання вашого додатку до прикліпленого інстансу (чи кластера – дивись ) на Bluemix. Двічі, поки я пробував це зробити – мій інстанс на Bluemix відвалювався. Встановивши Cloud Foundry cli, я таки розібрався в чому була проблема. Справа в тому, що після розгортання вашого застосунку, необхідно вказати ще і як його запускати. Для цього необхідно в корені проекту створити Procfile, в якому вписати відповідну команду: для цього проекту, наприклад, “web: node app.js”. Детальніше можна почитати в документації Heroku. Хоча, гадаю, з цим файлом – DevOps сервіс правильно розгортатиме ваш додаток. Консольна утиліта після логування працює дуже просто – вводите push команду з назвою вашого застосунку та списком сервісів, які прописані в маніфест-файлі:

applications:
- services:
- mongodb-kx
- Monitoring and Analytics-vf
- DevOps Services-m4
disk_quota: 1024M
host: itblogger
name: itblogger
command: node app.js
path: .
domain: ng.bluemix.net
instances: 1
memory: 128M

Після запуску скрипта розгортання – чекаємо деякий час для завантаження всіх залежностей, що прописані у вашому package.json файлі – і любуємося результатом:

core@core-lunaos:~/Documents/hub/itblogger$ cf push itblogger -c "node app.js"
Using manifest file /home/core/Documents/hub/itblogger/manifest.yml
Updating app itblogger in org hidden@gmail.com / space dev as hidden@gmail.com...
OK
Using route itblogger.ng.bluemix.net
Uploading itblogger...
Uploading app files from: /home/core/Documents/hub/itblogger
Uploading 7.6K, 14 files
OK
Binding service mongodb-kx to app itblogger in org hidden@gmail.com / space dev as hidden@gmail.com...
OK
Binding service Monitoring and Analytics-vf to app itblogger in org hidden@gmail.com / space dev as hidden@gmail.com...
OK
Binding service DevOps Services-m4 to app itblogger in org hidden@gmail.com / space dev as hidden@gmail.com...
OK
Stopping app itblogger in org hidden@gmail.com / space dev as hidden@gmail.com...
OK
Starting app itblogger in org hidden@gmail.com / space dev as hidden@gmail.com...
----- Downloaded app package (8.0K)
----- Downloaded app buildpack cache (4.4M)
OK
----- Buildpack Version: 20140529-1413
----- Resolving node version by IBM
----- Requested node range: 0.10.26
----- Resolved node version: 0.10.26
----- Installing IBM SDK for Node.js from admin cache
----- Read service config: MonitoringAndAnalytics.json at the start
----- Read service config: SQLDB_BLUAcceleration.json at the start
----- Restoring node_modules directory from cache
----- Pruning cached dependencies not specified in package.json
----- Writing a custom .npmrc to circumvent npm bugs
----- Installing dependencies
----- Caching node_modules directory for future builds
----- Cleaning up node-gyp and npm artifacts
----- Building runtime environment
----- Read service config: MonitoringAndAnalytics.json at the end
----- Application bound service: [MonitoringAndAnalytics]
----- Add service extension at the end of the application staging
----- Install local dependency: resources/monitoring/knj
knj-plugin@1.0.0 node_modules/knj-plugin
----- Found boot js file: app.js
----- Add header to app.js: require("knj-plugin");
----- Read service config: SQLDB_BLUAcceleration.json at the end
----- Uploading droplet (11M)

0 of 1 instances running, 1 down
1 of 1 instances running
App started
Showing health and status for app itblogger in org hidden@gmail.com / space dev as hidden@gmail.com...
OK
requested state: started
instances: 1/1
usage: 128M x 1 instances
urls: itblogger.ng.bluemix.net
state since cpu memory disk
#0 running 2014-06-09 07:55:26 PM 0.0% 46M of 128M 33.5M of 1G

До речі, про cf – кинувши оком на документацію – побачив у них можливість розгортання Python-застосунків через heroku. Детальніше – в документації.

Мушу зізнатися – матеріал писав дуже довго через постійні помилки то при створенні, то при видаленні, то при байндінгу сервісів … Але це бета. Тому буду лояльним. Як я і казав – Bluemix поки не може конкурувати з гігантами ринку, але перші кроки зроблено. Зараз важливо зібрати фідбеки, виправити помилки, додати стабільності і … Гадаю з тим темпом, з яким зростає популярність PааS систем, місце знайдеться і для IBM.

Буду завершувати. Взагалі, я планував писати великий матеріал про менеджер віртуальних оточень Vagrant та провайдери для Docker, AWS, VMWare, Hyper-V та багатьох інших кастомних технологій віртуалізації. Але, підозрюю, що створення власної хмари локально – це такий таск зайшов би ще складніше. Адже там потрібно писати всі маніфест-конфіги вручну. Тому, почавши з хостед-клаудів, я трохи спростив задачу. Звісно, IBM Bluemix – не найкращий кандидат для представлення віддалених хмар. Але багато поганого про цей сервіс я теж не скажу. Бета-версія і все таке інше. Підсумовуючи … А нє, просто – до зустрічі в наступному матеріалі.

.

Як ви вже зрозуміли, говорити будемо про алгоритми сортування. Принаймні, почнемо. Я впевнений, нікого не дивує така тема для початку, адже будь-які курси, книжки та навчальні матеріали на дану тематику починаються саме з алгоритмів сортування. Мої друзі, з якими я навчався в одній групі, якось заперечували мені необхідність обговорення та писання на дану тематику. Що ж, вони працюють програмістами, я – здебільшого адмініструю системи, інколи пишу, але для такої системи, де крім алгоритмів стільки проблем, що до роботи над алгоритмами ніколи не доходять руки. Тому, я довіряю їхнім словам, але, звісно ж, ні разу не погоджуюсь з ними. Отже, їхній аргумент – це все описано, інформація є на Вікіпедії і вона не настільки важлива, аби займати нею те місце в голові, яке можна використати раціональніше. Для мене такий підхід є абсолютно незрозумілим і, навіть, таким, який я логці не можу піддати. Я, наприклад, не знаю скільки ресурсів мозку можу використовувати, але впевнений, що без постійних навантажень та “зарядки” мозку все, що нам залишиться – це рахувати незайняті ресурси. Людський мозок – не мікрочіп із відомою кількістю комірок. Тому вичерпати його ресурси навряд чи комусь вдастся. А щодо того, що опис алгоритмів є на Вікі … Ну, табличка множення теж є на Вікі. Вірші Шевченка є на Вікі. Теореми Ньютона. Атомні маси чисел. Якщо ви не знаєте цих речей – ви не володієте знаннями. А інформація про місцезнаходження даних – це ще далеко не знання.

Отже, алгоритми сортування. Постановка задачі проста – є масив об’єктів, які містять значення ключів. Ключі треба впорядкувати у відповідності до якогось заздалегідь встановленого правила. Думаючи над тим, як уніфікувати подання реалізації алгоритмів, я розривався між варіантом використання всіх можливих засобів Python 3 чи більш низькорівневого подання. В результаті, вирішив знайти консенсус, уникаючи якихось готових інструментів python, які ховають логіку роботи програми для незнайомих з мовою користувачів.

Отже, що нам потрібно – це якось міряти ефективність алгоритмів. Для цього зручно міряти кількість звертань до алгоритму та змін в ньому, що напряму впливає на час виконання алгоритму.

"""Template for sort algorithm
Blog: itblogger.org.ua
"""

import timeit
import random

def generateShuffle(array):
    random.shuffle(array)
    return array

class Sorter:
    def __init__(self, obj):
        self.obj = [i for i in obj]
        self.startTime = 0
        self.endTime = 0

    def __str__(self):
        return "".join([str(i) + " " for i in self.obj])

    def isSorted(self):
        return all(self.obj[i] <= self.obj[i + 1] for i in range(len(self.obj) - 1))

    def sort(self):
        """
        Реалізація алгоритму
        """
        self.startTime = timeit.default_timer()

        for i in range(len(self.obj)):
            for j in range(i + 1, len(self.obj)):
                if self.obj[j] < self.obj[i]:
                    self.obj[j], self.obj[i] = self.obj[i], self.obj[j]

        self.endTime = timeit.default_timer()

    def runTime(self):
        return self.endTime - self.startTime

def main():
    lst = generateShuffle(list(range(100))) #генеруємо послідовність

    o = Sorter(lst) # створення сортувальника
    print("Unsorted:", o)

    o.sort()

    assert o.isSorted() == True, "Sequence is not sorted" # перевірка сортованості

    print("Sorted:", o, "Time:", o.runTime(), sep="\n")


main()

Результат:

Unsorted: 25 56 76 92 78 21 49 34 20 53 77 31 82 62 68 51 60 57 72 37 97 8 86 50 65 94 35 33 73 48 99 23 64 30 88 75 19 16 2 66 81 70 24 44 83 41 45 90 29 18 17 1 11 95 7 43 36 67 80 5 63 47 52 98 55 4 10 39 9 93 79 13 3 87 89 42 12 38 59 26 40 15 54 22 58 74 85 32 69 71 61 91 14 27 46 0 84 96 28 6
Sorted:
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99
Time:
0.0018363387404734194

Поки хтось на зачепився – так, я знаю, писати геттери та сеттери треба з @property, бо втрачається вся інкапсуляція а з нею класична безпечна об’єктна орієнтованість. Давайте, поки, упустимо ці речі. Отже, для реалізації наших алгоритмів будемо використовувати якийсь узагальнений клас із методом sort(), де буде реалізація сортування, перевірка об’єкта на відсортованість та метод відображення послідовності. Звісно, назвати такий клас універсальним щодо типів складно, але для базових стрічок та чисел цього буде достатньо. З часом, скоріш за все, кожен метод доведеться переписувати під складніші типи даних. В якості прикладу роботи такої узагальненої схеми я використав славнозвісний метод бульбашки. Ми його навіть не розглядаємо, але для прикладу згодиться. Використаємо ще невеличку функцію для генерування випадкових послідовностей і таймери для вимірювання часу роботи алгоритму.

Ну от, базову схему накидали, продовжимо іншим разом, бо лікарняний вже закінчився, а Skyrim ще багато місій має. Я побіг.