Съвременна платформа за разработка и внедряване на софтуер

Това е първата публикация в серия от материали, посветени на промените, подобренията и добавките в предстоящото обновление на платформата Red Hat OpenShift до 4.0, които ще помогнат за подготовката за прехода към новата версия.

Съвременна платформа за разработка и внедряване на софтуер

От момента, в който представителите на едва създаващата се общност на Kubernetes се събраха за първи път през есента на 2014 година в офисите на Google в Сиатъл, вече беше ясно, че проектът Kubernetes е предопределен да промени коренно съвременните подходи при разработването и внедряването на софтуер. В същото време публичните облачни доставчици продължаваха активно да инвестират в развитието на инфраструктура и услуги, което значително улесни и опрости работата с ИТ и създаването на софтуер, правейки ги невероятно достъпни, нещо, което малко хора можеха да си представят в началото на десетилетието.

Разбира се, анонсът на всяка нова облачна услуга беше съпроводен с многобройни обсъждания на експерти в Тwitter, като споровете обхващаха най-различни теми – включително края на ерата на отворените кодове, залеза на локалното ИТ (on-premises IT), неизбежността на нова софтуерна монополия в облака и как новата парадигма X ще замени всички останали.

Няма нужда да се казва, че всичките тези спорове бяха доста глупави.

Реалността е, че нищо не изчезва, и днес можем да наблюдаваме експоненциален растеж на крайни продукти и методи за тяхното разработване, свързано с постоянната поява на нов софтуер в нашия живот. И въпреки че всичко около нас ще се променя, по същество всичко остава непроменено. Разработчиците все така ще пишат код с грешки, експлоатационните инженери и специалисти по надеждност ще продължат да носят пейджъри и да получават автоматични известия в Slack, мениджърите ще оперират с понятията OpEx и CapEx, и всеки път, когато настъпи неизправност, старшият разработчик ще въздъхне тъжно с думите: „Видяхте ли?“

Наистина, би трябвало да се обсъди, това е какви инструменти можем да получим, за да създадем по-качествени софтуерни продукти, и как те ни позволяват да повишим сигурността и да направим разработката по-лесна и надеждна. С увеличаването на сложността на проектите се появяват нови рискове, а днес животите на хората зависят толкова от софтуера, че разработчиците просто са задължени да се стараят да вършат работата си по-добре.

Kubernetes е един от тези инструменти. Работи се по това да бъдат обединени с други инструменти и услуги в рамките на Red Hat OpenShift в единна платформа, която да направи софтуера по-надежден, по-лесен за управление и безопасен за потребителите.

С оглед на казаното, екипът на OpenShift си задава един прост въпрос:

Как може да се направи работата с Kubernetes по-лесна и удобна?

Отговорът е учудващо очевиден:

  • да автоматизираме сложните моменти в разгръщането на облака или извън облака;
  • да се фокусираме върху надеждността, докато скриваме сложността;
  • да продължаваме постоянната работа по пускането на прости и безопасни обновления;
  • да постигнем контролируемост и възможност за одит;
  • да се стремим от самото начало да осигурим висока сигурност, но не за сметка на удобството за ползване.

Следващото издание на OpenShift трябва да вземе предвид както опита на създателите, така и опита на други разработчици, внедряващи софтуера в голям мащаб в най-големите компании по света. Освен това, в него се нуждае да се отчете целият натрупан опит от отворените екосистеми, които днес лежат в основите на съвременния свят. В същото време е необходимо да се откаже от предишния манталитет на любител разработчик и да се премине към нова философия на автоматизираното бъдеще. Това трябва да бъде „мост“ между предишните и новите начини за разгръщане на софтуер и напълно да се използва цялата налична инфраструктура – независимо дали тя се обслужва от най-големия облачен доставчик или е пусната на малки системи на периферията.

Как да постигнем такъв резултат?

В Red Hat е прието да се извършва дълго време скучна и неблагодарна работа, за да се запази създаденото общество и да не се допусне затварянето на проектите, в които компанията участва. В open-source обществото има огромно количество талантливи разработчици, които създават най-необикновени неща - развлекателни, обучаващи, отварящи нови възможности и просто красиви, но, разбира се, никой не очаква, че всички участници ще вървят в една посока или ще преследват общи цели. Използването на тази енергия и пренасочването ѝ в нужната посока понякога е необходимо за развитието на направления, които биха били полезни за нашите потребители, но същевременно трябва да следим развитието на нашите общности и да се учим от тях.

В началото на 2018 година Red Hat придоби проекта CoreOS, който имаше сходни виждания за бъдещето - по-сигурно и надеждно, създавано на принципите на open-source. Компанията работеше върху по-нататъшното развитие на тези идеи и тяхната реализация, осъществявайки нашата философия - стремейки се да осигури безопасна работа на всичкото программно осигуряване. Цялата тази работа се основава на Kubernetes, Linux, публични облаци, частни облаци и хиляди други проекти, които лежат в основата на нашата съвременна цифрова екосистема.

Новото издание на OpenShift 4 ще бъде интуитивно, автоматизирано и по-естествено.

Платформата OpenShift ще работи с най-добрите и надеждни операционни системи Linux, с bare-metal хардуерна поддръжка, удобна виртуализация, автоматично програмиране на инфраструктурата и, разбира се, контейнери (които всъщност са просто образи на Linux).

Платформата трябва да бъде безопасна от самото начало, но същевременно да осигурява възможността за удобни итерации за разработчиците - тоест да притежава достатъчна гъвкавост и надеждност, като същевременно позволява на администраторите да извършват одит и да осигуряват удобство при управлението.

Тя трябва да позволява стартирането на софтуера „като услуга“ и да не доведе до неконтролирано увеличаване на инфраструктурата за операторите.

Тя ще позволи на разработчиците да се фокусират върху създаването на реални продукти за потребителите и клиентите. Няма да се налага да се преборват с джунглата от настройки на хардуер и софтуер, а всички случайни усложнения ще останат в миналото.

OpenShift 4: NoOps платформа, която не изисква поддръжка

В тази публикация Описани са задачите, които помогнаха да се формира визията на компанията относно OpenShift 4. Задачата на екипа е в максимална степен да опрости ежедневните задачи по експлоатация и поддръжка на софтуер, да направи тези процеси лесни и не натоварващи – както за специалистите, занимаващи се с внедряване, така и за разработчиците. Но как може да се приближим до тази цел? Как да създадем платформа за стартиране на софтуер, която изисква минимално намесване? Какво всъщност означава NoOps в този контекст?

Ако се опитате да се абстрахирате, то за разработчиците понятията „безсърврени“ или „NoOps“ означават инструменти и услуги, които позволяват да се скрие „експлоатационният“ компонент или да се минимизира това бреме за разработчика.

  • Работете не със системи, а с приложни интерфейси (API).
  • Не се занимавайте с внедряване на софтуер – нека вместо вас това да прави провайдър.
  • Не бива да се захващате веднага за създаването на голям фреймворк – започнете с написването на малки фрагменти, които да служат като „строителни блокове“, опитайте се този код да работи с данни и събития, а не с дискове и бази данни.

Задачата, както и преди, е да се ускорят итерациите при разработка на софтуер, да се осигури възможност за създаване на по-качествени продукти и да може разработчикът да не се тревожи за системите, на които се изпълнява неговият софтуер. Опитен разработчик добре разбира, че ако се фокусира на потребителите, картината може бързо да се промени, така че не бива да инвестирате твърде много усилия в написване на софтуер, ако нямате абсолютна увереност в неговата необходимост.

За специалистите, ангажирани в поддръжката и експлоатацията, терминът „NoOps“ може да звучи малко плашещо. Но по време на разговори с инженери по експлоатация става очевидно, че използваните от тях модели и методи, насочени към осигуряване на надеждност (Site Reliability Engineering, SRE), в голяма степен кореспондират с описаните по-горе модели:

  • Не управлявайте системите – автоматизирайте процесите за управление на тях.
  • Не се занимавайте с внедряване на софтуер – създайте пайплайн за неговото разгръщане.
  • Опитайте се да не обединявате всички ваши услуги и не допускайте отказ на една от тях да причинява отказ на цялата система – разпределяйте ги из цялата инфраструктура, използвайки средства за автоматизация, и ги свързвайте, предвидили възможност за контрол и наблюдение.

Специалистите по SRE знаят, че нещо може да се обърка и те ще трябва да проследят и отстранят проблема – затова автоматизират рутинната работа и предварително определят допустимите отклонения (error budgets), за да бъдат готови да приоритизират и вземат решения при възникване на проблем.

Kubernetes в OpenShift е платформа, създадена да реши две основни задачи: вместо да ви накара да се справяте с виртуални машини или API интерфейси на балансировачите на натоварване, се работи с абстракции от по-високо ниво – с процеси на разгръщане и услуги. Вместо да инсталирате софтуерни агенти, можете да стартирате контейнери, а вместо да пишете собствен стек за мониторинг, използвайте наличните в платформата инструменти. По този начин, тайният ингредиент на OpenShift 4 всъщност не е никаква тайна – просто трябва да приемете принципите на SRE и безсървърните концепции и да ги доведете до логичен край, в помощ на разработчиците и инженерите по експлоатация:

  • Автоматизирайте и стандартизирайте инфраструктурата, която се използва от приложенията
  • Свържете заедно процесите на разгръщане и разработка, без да ограничавате самите разработчици
  • Постигнете целта стартирането, одита и осигуряването на безопасността на стотния сервис, функция, приложение или цял стек да бъдат ни най-малко по-сложни от стартирането на първия.

Каква е разликата между платформата OpenShift 4 и предшествениците й, както и с „стандартния“ подход за решаване на подобни проблеми? Как се постига мащабиране за екипите, ангажирани с внедряването и експлоатацията? Отговорът е, че основната роля играе кластерът. И така,

  • Нека направим така, че целта на кластерите да бъде ясна (Скъпо облако, този кластер създадох, защото мога)
  • Машините и операционните системи съществуват, за да обслужват кластера (Ваше Величество)
  • Управлявайте състоянието на хостовете от кластера, минимизирайте тяхното пренареждане (drift).
  • За всеки важен елемент от системата е необходим механизъм (гледач), който ще следи и отстранява проблемите.
  • Аварията на *всеки* аспект или елемент от системата изисква съответните механизми за възстановяване — това е обичайна част от живота.
  • Цялата инфраструктура трябва да се конфигурира чрез API.
  • Използвайте Kubernetes за стартиране на Kubernetes. (Да, да, това не е печатна грешка)
  • Актуализациите трябва да се инсталират лесно и удобно. Ако за инсталирането на актуализация е необходима повече от една клик, явно нещо не е наред.
  • Мониторингът и отстраняването на всеки компонент не трябва да създават проблеми, а следователно и проследяването и съставянето на отчети за цялата инфраструктура също трябва да бъде просто и удобно.

Искате ли да видите как платформата работи на практика?

Предварителната версия на OpenShift 4 стана достъпна за разработчици. С помощта на лесен за използване инсталатор можете да стартирате кластер на AWS на базата на Red Hat CoreOS. За да се възползвате от предварителната версия, ви е необходим само акаунт в AWS за предоставяне на инфраструктура и набор от акаунти за достъп до образите на предварителната версия.

  1. За да започнете работа, посетете try.openshift.com и кликнете върху “Get Started”.
  2. Влезте в акаунта си в Red Hat (или създайте нов) и следвайте инструкциите, за да настроите своя първи кластер.

След успешна инсталация, се запознайте с нашите обучителни материали OpenShift Training, за да получите по-подробно разбиране за системите и концепциите, които правят платформата OpenShift 4 толкова прост и удобен инструмент за стартиране на Kubernetes.

Опитайте новото издание на OpenShift и споделете мнението си. Стремим се да направим работата с Kubernetes максимално достъпна и без усилия – бъдещето NoOps започва днес.

А сега внимание!
На конференцията DevOpsForum 2019 На 20 април един от разработчиците на OpenShift, Вадим Рутковски, ще проведе майсторски клас — ще счупи десет клъстера и ще накара участниците да ги поправят. Конференцията е платена, но с промокод #RedHat има отстъпка от 37%.

Майсторският клас е от 17:15 до 18:15, а щандът работи през целия ден. Тениски, шапки, стикери — както обикновено!

Зала #2
«Тук трябва да се промени цялата система: поправяме счупените k8s клъстери заедно с сертифицирани специалисти».

Източник: habr.com

Купете надежден хостинг за сайтове със защита от DDoS, VPS и VDS сървъри 🔥 Купете надежден хостинг за сайтове със защита от DDoS, VPS и VDS сървъри | ProHoster