Това е първата от поредица публикации за промените, подобренията и допълненията в предстоящата актуализация на платформата Red Hat OpenShift 4.0, която ще ви помогне да се подготвите за прехода към новата версия.
От момента, в който новоизлюпената общност на Kubernetes се събра за първи път в офиса на Google в Сиатъл през есента на 2014 г., беше ясно, че проектът Kubernetes е предназначен да революционизира начина, по който софтуерът се разработва и внедрява днес. В същото време доставчиците на публични облачни услуги продължиха да инвестират активно в развитието на инфраструктура и услуги, което направи работата с ИТ и създаването на софтуер много по-лесна и достъпна и ги направи невероятно достъпни, което малцина можеха да си представят в началото на десетилетието.
Разбира се, обявяването на всяка нова облачна услуга беше придружено от многобройни дискусии между експерти в Twitter и дебати бяха проведени по различни теми - включително края на ерата на отворения код, упадъка на локалните ИТ и неизбежността на нов софтуерен монопол в облака и как новата парадигма X ще замени всички останали парадигми.
Излишно е да казвам, че всички тези спорове бяха много глупави
Реалността е, че нищо няма да изчезне и днес можем да видим експоненциален растеж на крайните продукти и начина, по който те се разработват, поради постоянната поява на нов софтуер в живота ни. И въпреки факта, че всичко наоколо ще се промени, в същото време по същество всичко ще остане непроменено. Разработчиците на софтуер все още ще пишат код с грешки, оперативните инженери и специалистите по надеждност все още ще се разхождат с пейджъри и ще получават автоматични предупреждения в Slack, мениджърите ще продължат да работят по отношение на OpEx и CapEx и всеки път, когато възникне повреда, старшият разработчик ще тъжна въздишка с думите: “Нали ти казах”...
наистина ли трябва да се обсъди, е какви инструменти можем да имаме на наше разположение, за да създадем по-добри софтуерни продукти и как те могат да подобрят сигурността и да направят разработката по-лесна и по-надеждна. Тъй като проектите стават по-сложни, възникват нови рискове и днес животът на хората е толкова зависим от софтуера, че разработчиците просто трябва да се опитат да вършат работата си по-добре.
Kubernetes е един такъв инструмент. Работи се по комбинирането на Red Hat OpenShift с други инструменти и услуги в една платформа, която ще направи софтуера по-надежден, по-лесен за управление и по-безопасен за потребителите.
С това казано, екипът на OpenShift задава един прост въпрос:
Как можете да направите работата с Kubernetes по-лесна и удобна?
Отговорът е изненадващо очевиден:
- автоматизирайте сложни аспекти на внедряване в облака или извън облака;
- съсредоточете се върху надеждността, като скриете сложността;
- продължите да работите непрекъснато за пускане на прости и сигурни актуализации;
- постигане на контролируемост и одитируемост;
- стремят се първоначално да гарантират висока сигурност, но не за сметка на използваемостта.
Следващата версия на OpenShift трябва да вземе предвид както опита на създателите, така и опита на други разработчици, които внедряват софтуер в голям мащаб в най-големите компании в света. Освен това трябва да вземе предвид целия натрупан опит от отворени екосистеми, които са в основата на съвременния свят днес. В същото време е необходимо да се изостави старият манталитет на аматьорския разработчик и да се премине към нова философия на автоматизирано бъдеще. Той трябва да преодолее пропастта между старите и новите начини за внедряване на софтуер и да се възползва напълно от цялата налична инфраструктура - независимо дали се хоства от най-големия доставчик на облак или работи на малки системи на ръба.
Как да постигнете този резултат?
В Red Hat е обичайно да се върши скучна и неблагодарна работа за дълго време, за да се запази установената общност и да се предотврати закриването на проекти, в които компанията участва. Общността с отворен код съдържа огромен брой талантливи разработчици, които създават най-необикновени неща - забавни, образователни, отварящи нови възможности и просто красиви, но, разбира се, никой не очаква всички да се движат в една и съща посока или да преследват общи цели . Използването на тази енергия и пренасочването й в правилната посока понякога е необходимо за развитие на области, които биха били от полза за нашите потребители, но в същото време трябва да наблюдаваме развитието на нашите общности и да се учим от тях.
В началото на 2018 г. Red Hat придоби проекта CoreOS, който имаше сходни виждания за бъдещето - по-сигурен и надежден, създаден на принципите на отворения код. Компанията работи за по-нататъшното развитие на тези идеи и тяхното прилагане, прилагайки нашата философия на практика - опитвайки се да гарантира, че целият софтуер работи безопасно. Цялата тази работа е изградена върху Kubernetes, Linux, публични облаци, частни облаци и хиляди други проекти, които са в основата на нашата съвременна цифрова екосистема.
Новата версия на OpenShift 4 ще бъде ясна, автоматизирана и по-естествена
Платформата OpenShift ще работи с най-добрите и най-надеждните операционни системи Linux, с хардуерна поддръжка на голи метали, удобна виртуализация, автоматично програмиране на инфраструктурата и, разбира се, контейнери (които по същество са само изображения на Linux).
Платформата трябва да бъде защитена от самото начало, но все пак да позволява на разработчиците лесно да итерират – тоест да бъде достатъчно гъвкава и сигурна, като същевременно позволява на администраторите да я проверяват и управляват лесно.
То трябва да позволява софтуерът да се изпълнява „като услуга“ и да не води до неуправляем растеж на инфраструктурата за операторите.
Това ще позволи на разработчиците да се съсредоточат върху създаването на реални продукти за потребители и клиенти. Няма да се налага да газите през джунглата от хардуерни и софтуерни настройки и всички случайни усложнения ще останат в миналото.
OpenShift 4: NoOps платформа, която не изисква поддръжка
В описа онези задачи, които помогнаха за оформянето на визията на компанията за OpenShift 4. Целта на екипа е да опрости ежедневните задачи по работа и поддръжка на софтуера, доколкото е възможно, да направи тези процеси лесни и спокойни - както за специалистите, участващи в внедряването, така и за разработчиците. Но как можете да се доближите до тази цел? Как да създадем платформа за работещ софтуер, която изисква минимална намеса? Какво изобщо означава NoOps в този контекст?
Ако се опитате да се абстрахирате, тогава за разработчиците понятията „без сървър“ или „NoOps“ означават инструменти и услуги, които ви позволяват да скриете „оперативния“ компонент или да минимизирате тази тежест за разработчика.
- Работете не със системи, а с интерфейси на приложения (API).
- Не си правете труда да внедрявате софтуер - оставете доставчика да го направи вместо вас.
- Не се захващайте веднага със създаването на голяма рамка - започнете с писане на малки части, които ще действат като "градивни елементи", опитайте се да накарате този код да работи с данни и събития, а не с дискове и бази данни.
Целта, както и преди, е да се ускорят итерациите в разработката на софтуер, да се осигури възможност за създаване на по-добри продукти и така разработчикът да не се тревожи за системите, на които работи софтуерът му. Един опитен разработчик е наясно, че фокусирането върху потребителите може бързо да промени картината, така че не трябва да влагате твърде много усилия в писането на софтуер, освен ако не сте напълно сигурни, че е необходим.
За професионалистите по поддръжката и експлоатацията думата „NoOps“ може да звучи малко плашещо. Но когато общувате с полеви инженери, става очевидно, че моделите и техниките, които използват, насочени към осигуряване на надеждност и надеждност (Site Reliability Engineering, SRE), имат много прилики с моделите, описани по-горе:
- Не управлявайте системи – автоматизирайте процесите на тяхното управление.
- Не внедрявайте софтуер - създайте тръбопровод, за да го внедрите.
- Избягвайте да обединявате всичките си услуги заедно и да оставяте отказът на една да доведе до отказ на цялата система – разпръснете ги в цялата си инфраструктура с помощта на инструменти за автоматизация и ги свържете по начини, които могат да бъдат наблюдавани и наблюдавани.
SRE знаят, че нещо може да се обърка и ще трябва да проследят и отстранят проблема - така че автоматизират рутинната работа и задават бюджети за грешки предварително, така че да са готови да приоритизират и да вземат решения, когато възникне проблем.
Kubernetes в OpenShift е платформа, създадена да решава два основни проблема: вместо да ви принуждава да разбирате виртуални машини или API за балансиране на натоварването, тя работи с абстракции от по-висок порядък – процеси на внедряване и услуги. Вместо да инсталирате софтуерни агенти, можете да стартирате контейнери и вместо да пишете свой собствен стек за наблюдение, използвайте инструментите, които вече са налични в платформата. И така, тайният сос на OpenShift 4 наистина не е тайна - това е просто въпрос на вземане на принципите на SRE и концепциите без сървър и тяхното логично завършване, за да помогне на разработчиците и оперативните инженери:
- Автоматизирайте и стандартизирайте инфраструктурата, която приложенията използват
- Свържете процесите на внедряване и разработка, без да ограничавате самите разработчици
- Гарантирането, че стартирането, одитирането и защитата на XNUMX-та услуга, функция, приложение или целия стек не е по-трудно от първото.
Но каква е разликата между платформата OpenShift 4 и нейните предшественици и от „стандартния“ подход за решаване на подобни проблеми? Какво стимулира мащаба на екипите за внедряване и операции? Поради факта, че царят в тази ситуация е клъстерът. Така,
- Уверяваме се, че целта на клъстерите е ясна (Скъпи облак, взех този клъстер, защото можех)
- Машините и операционните системи съществуват, за да обслужват клъстера (Ваше Величество)
- Управлявайте състоянието на хостове от клъстера, минимизирайте тяхното повторно изграждане (дрифт).
- За всеки важен елемент от системата е необходим Nanny (механизъм), който ще следи и отстранява проблемите
- Отказът на *всеки* аспект или елемент от системата и свързаните с тях механизми за възстановяване са нормална част от живота
- Цялата инфраструктура трябва да бъде конфигурирана чрез API.
- Използвайте Kubernetes, за да стартирате Kubernetes. (Да, да, това не е печатна грешка)
- Актуализациите трябва да са лесни и безпроблемни за инсталиране. Ако е необходимо повече от едно кликване за инсталиране на актуализация, тогава очевидно правим нещо нередно.
- Мониторингът и отстраняването на грешки във всеки компонент не би трябвало да е проблем и следователно проследяването и докладването в цялата инфраструктура също трябва да бъде лесно и удобно.
Искате ли да видите възможностите на платформата в действие?
Предварителна версия на OpenShift 4 стана достъпна за разработчиците. С лесен за използване инсталатор можете да стартирате клъстер на AWS върху Red Had CoreOS. За да използвате визуализацията, имате нужда само от акаунт в AWS, за да предоставите инфраструктурата, и набор от акаунти за достъп до изображенията за визуализация.
- За да започнете, отидете на и щракнете върху „Първи стъпки“.
- Влезте в акаунта си в Red Hat (или създайте нов) и следвайте инструкциите, за да настроите първия си клъстер.
След успешна инсталация вижте нашите уроци за да получите по-задълбочено разбиране на системите и концепциите, които правят платформата OpenShift 4 толкова лесен и удобен начин за стартиране на Kubernetes.
Опитайте новата версия на OpenShift и споделете мнението си. Поели сме ангажимент да направим работата с Kumbernetes възможно най-достъпна и лесна – бъдещето на NoOps започва днес.
Сега внимание!
На конференцията На 20 април един от разработчиците на OpenShift, Вадим Рутковски, ще проведе майсторски клас - той ще разбие десет клъстера и ще ги принуди да ги поправят. Конференцията е платена, но с промоционален код #RedHat получавате 37% отстъпка
Майсторски клас от 17:15 - 18:15, а щандът е отворен през целия ден. Тениски, шапки, стикери - обичайното!
Зала №2
„Тук цялата система трябва да бъде променена: ние поправяме счупени k8s клъстери заедно със сертифицирани механици.“
Източник: www.habr.com