microdevops.com-Open Source DevOps Engineering For Small and Medium Business

Наші можливості

Ми можемо

Допомогти клієнту вирішити, який використовувати хостинг серверів та віртуалізації

Ми можемо працювати з:

Виділені сервери на голому залізі та VPS, що надаються

Віртуальні машини та контейнери

  • Віртуальні машини на виділених серверах – KVM
  • Linux containers на виділених серверах або VPS
  • Кластера віртуалізації типу Proxmox VE або LXD
  • Docker, Kubernetes, Nomad та інші рішення для контейнеризації

Хмарні інстанси

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

Ми рекомендуємо використовувати хмари лише тоді, коли їхнє використання виправдане: програмна масштабованість, мультитенантність на вимогу, мультирегіональні вимоги тощо. На нашу думку, хмари не є найкращим варіантом для простого налаштування, наприклад Інтернет-порталу чи магазину з постійним навантаженням: це коштуватиме дорожче і працюватиме гірше. Люди схильні неправильно використовувати хмари.

Після прийняття рішення про те, що використовувати, ми допомагаємо клієнту зареєструватися на послугу. Часто клієнт ділиться з нами доступом до служби управління хостингом. Ми зберігаємо секрети доступу клієнта в безпеці за допомогою приватного сховища паролів.

Встановити операційну систему та підключити до набору інструментів Microdevops

Ми завжди намагаємося звести до мінімуму частину ручного налаштування сервера. Ми маємо великий досвід роботи з Ubuntu і Debian і розробляємо пакети інструментів і код керування конфігурацією для них. Як тільки ОС буде встановлено, бажано також з використанням автоматизації, ми продовжуємо налаштування сервера декларативно за допомогою коду.

Розгорнути власну інфраструктуру

Деяким навіть невеликим клієнтам потрібна власна інфраструктура стеку DevOps через нормативні акти, міркування безпеки тощо. Ось чому ми розробили наш підхід, враховуючи мультітенансі. Тож за бажанням клієнта ми можемо розгорнути власний екземпляр GitLab клієнта, сервер SaltStack тощо та застосовувати той самий підхід, що й у нашій власній інфраструктурі, але керувати власними службами клієнта. Звичайно, клієнт має набагато більше контролю над основними компонентами, якщо вони є його власними. Поки ми керуємо власними серверами інфраструктури клієнта, усі вони потребують ліцензій Microdevops.

Розгорнути додатки

Ми маємо досвід розгортання та налаштування таких додатків, як:

  • сайти з nginx/php
  • сайти з nginx/python
  • сайти з nginx/ruby
  • статичні сайти з nginx
  • MySQL (Percona варіант)
  • PostgreSQL
  • MongoDB
  • RabbitMQ
  • Kubernetes кластер
  • Softether, Wireguard, OpenVPN VPN
  • GitLab

Та багато інших. Список додатків, які ми розгортаємо за допомогою коду, доступний тут.

Довгостроково підтримувати

Нам подобаються рішення, які працюють багато років. Ми підтримуємо деякі налаштування серверів для наших клієнтів уже більше 10 років, мігруючи крізь машини, оновлюючи ОС і програми. Ми розробляємо наші інструменти для уніфікації моніторингу та резервного копіювання, які необхідні для довгострокової підтримки.

Забезпечити якісний інжиніринг

Ми працюємо з досить невеликими сетапами. Ідея Microdevops полягає в тому, щоб надати стек передових технологій як послугу для маленьких клієнтів, допомогти їм зрозуміти та використовувати його переваги.

Керувати політикою доступу

Усі сервери, якими ми керуємо, використовують політику закритого Firewall. За замовчуванням всі вхідні порти приватних служб, як-то SSH і бази даних, закриті з Інтернету. За допомогою Infrastructure as Code ми керуємо списками доступу статичних IP-адрес, яким дозволено підключення. Ми використовуємо приватні сервери VPN, якщо статичні IP-адреси недоступні для клієнта..

Керувати конфігураціями

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

Консультувати

Не всі розробники програмного забезпечення належать є Full-Stack та мають досвід DevOps. Також добре зосереджуватися на певній частині технології. Це дозволяє зануритися глибше та дізнатися більше. Ми консультуємо та допомагаємо невеликим командам розробників щодо використання DevOps (Git, Docker, Kubernetes, репозиторії, регістрі, CI та Pipelines, автоматизація) з конкретними продуктами, які ми знаємо найкраще: GitLab, SaltStack, Ubuntu.

Ми можемо надати командам розробників налаштування динамічних dev середовищ, які автоматично створюються та видаляються для гілок або тегів Git у кластері Kubernetes за допомогою GitLab Pipelines і візуального доступу до кластера через Rancher. Це схоже на GitLab Auto-DevOps, але Auto-DevOps має більше обмежень. Крім того, ми не зберігаємо дані зі збереженням стану в кластерах Kubernetes – ми налаштовуємо бази даних і сховище лише на класичній інфраструктурі.

Ми можемо проконсультувати щодо правильного використання таких технологій:

  • DNS (Cloudflare)
  • SSL сертифікати (Let’s Encrypt автоматизація за допомогою acme.sh, CertBot)
  • Anti-DDOS (Cloudflare, Nginx)
  • Git branches, tags, sub-modules, flow
  • MySQL (Percona), PostgreSQL fine-tuning
  • Продуктивність серверів
  • Бекапи
  • Моніторинг
  • Інші задачі системного адміністрування серверів

Ми не можемо

Підтримувати іншу легасі архітектуру

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

Порушити наші принципи

Наприклад, ми ніколи не погоджуємося відмовлятися від політики закритого Firewall на сервері клієнта. Цей принцип може бути дуже не зручним для розробників і вони намагаються його саботувати. Але цей підхід має так багато переваг з точки зору безпеки, тому ми не можемо діяти іншим чином. Ми завжди попереджаємо клієнта, що ми не можемо виконати конкретне завдання, тому що це компрометує наш підхід.

Використовувати будь-які тихнології

Ми сильні у власній архітектурі, і ми хочемо зосередитися на деяких конкретних технологіях, яким ми надаємо перевагу. Ми не можемо дати клієнту зобов’язання використовувати будь-яку технологію, яку він або вона бажає. Наприклад, ми не будемо встановлювати Jenkins і його Pipelines, тому що його ідеологія нам чужа, поки що ми використовуємо в основному GitLab. Ми не будемо використовувати Ansible, Puppet або Chef, тому що 100% нашого досвіду керування конфігурацією знаходиться в SaltStack.

Замінити розробників клієнта

Незважаючи на те, що ми можемо покрити більшу частину запитів щодо серверів та інфраструктури клієнта, ми не можемо замінити всі інші необхідні інженерні спеціальності. Ми завжди намагаємося надати клієнту інформацію про наші можливості та про те, чи відповідає завдання нашому підходу чи ні. Наприклад, ми не можемо написати код програми клієнта, виправити теми WordPress, оновити плагіни тощо.