Про ІТ-кар’єризм, професійний ріст та ісландських баранів

Почну з баранів, бо, як виявилося, колись смішна історія має зовсім реальний приклад застосування.

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

Distributed-cluster на коліні | Nomad

Цей допис планувався як продовження теми CROSS-PROVIDER IAAS та логічне завершення розмов про такі популярні інструменти від HashiCorp як Packer та Terraform. Зовсім недавно Хашимото&Co випустили новий продукт Otto, який називають нащадком Vagrant. Чому не зробили новий реліз Vagrant? Це перше питання, яке я собі ставив, перед тим, як почитав документацію.

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

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

Cross-provider IAAS на стероїдах | Terraform&Packer | Ch2

Продовжую тему, почату в попередньому матеріалі. До речі, за час, поки я готував другу частину, з’явився матеріал для третьої, тому, імовірно, буде продовження.
Отож, в нас є конфігурації для збирання AMI для AWS та образів для Virtualbox. Щоб не ускладнювати собі життя із preseeding-ом, обмежимося хмарними провайдерами дял побудови нашої інфраструктури. Зрештою, цеі є головною метою. А збирання платформи для тестів – це вже індивідуально для кожного інженера.

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

Cross-provider IAAS на стероїдах | Terraform&Packer | Ch1

Традиційний абзац про те, чому я так давно не писав нічого.  Мав трохи подорожей. Німеччині, Швейцарія, Ісландія. Змінив роботу. Переїхав у інше місто. Поки звикаю до нових умов та завдань, часу на селф-девелопмент було не так багато. Проте, тема, про яку я хочу трохи поговорити – одна з трьох, які давно знаходяться на такому собі порядку денному. Перша – це створення приватної хмари з блекджеком і … докерами (Docker&Swarm). Друга тема – це CRIU – інструмент від розробників Parallels, який покликаний забезпечити реалізацію live-migration через checkpoint/restore стану запущених процесів, чи, зокрема, таких популярних зараз контейнерів. Але ця тема трохи пригальмувала, оскільки моєю кінцевою метою була демонстрація відновлення docker-контейнерів з допомогою CRIU, але через критичні зміни в libcontainer демонстрація накрилася, матеріал відсунувся “на потім”.

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

Битва за контейнери. Учасники та перспективи

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

Continue reading

Контейнерна віртуалізація. 3. CoreOS

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

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

Continue reading

Контейнерна віртуалізація. 2. Провайдери

Аби довго не запрягати з нудними вступами, перейдемо одразу до теми. Отже, минулого разу я пробував трохи розповідати про Vagrant. І зачепив декількома словами провайдерів віртуалізації. Прикладом виступив Virtualbox як базовий провайдер для Vagrant. Сьогодні ж я розповім і про деякі інші методи віртуалізації та провайдери, які допомагають з легкістю піднімати нові віртуальні середовища. Зауважте, я часто кажу – віртуальні середовища і це не випадково – не плутайте VE зі “справжніми” віртуалками. Linux Containers – це ізольовані середовища, які працюють на одному ядрі хостової машини. Власне, хто мав справу із Solaris або FreeBSD – там є свої аналоги – Containers та Jails відповідно.

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

LXC

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

Контейнерна віртуалізація. 1. Vagrant

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

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

Continue reading

PaaS IBM Bluemix – новий гравець на ринку?

Привіт піпли. Так, це таки сталося. Я всівся, нарешті, у крісло і вирішив зробити допис до цього блогу. Останні місяці якось все було складно із справами в глобальному оточенні, тому і не до писанини було. Та і зараз все не набагато краще. Ситуація не виглядає такою, яка вирішиться в короткій перспективі, тому спробую трохи відволіктись і розповісти вам про одного з “новачків” на ринку клауд-платформ – Bluemix від IBM.

Чому я взяв новачок у лапки? Ну, називати ІТ-гіганта 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, окрім потужної дослідницької команди, може робити якісний продукт у сфері хмарних обчислень.

Continue reading

Алгоритми та структури даних. Шаблон класу

Привіт піпли. Трохи затягнув я із продовженням теми алгоритмів та структур даних. Революційні настрої, невеличка операція на носі та інші непередбачувані проблеми трохи вибили мене з колії. З непередбачуваних проблем, звісно, треба згадати Skyrim, яким я вирішив розбавити двотижневе лікування вдома. Тому сьогодні постараюся без довгих прелюдій перейти до суті.

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

Continue reading