Какво трябва да знаете, за да станете начинаещ системен инженер (devops)
DevOps не е професия. Това е името на културата на доставяне на код от разработчика (dev) през тестери до системния администратор (ops) и обратна връзка по тази верига.
Обикновено се посочва лицето, което внедрява DevOps. както искат. Най-често това се прави от някой неконформист в екипа.
Професиите, които ще бъдат нарисувани в процеса на изграждане на тази методика са следните:
- Build Engineer е инженер, който управлява зависимости, компилации, кодови конфликти.
- Release Engineer - инженер, който управлява кодовото хранилище (кой къде слива и по какви правила и къде дрънка). Може би това е най-трудната задача в големите проекти. Особено при нестриктни Agile или Waterfall.
- Инженер по автоматизация - инженер, който автоматизира рутинни задачи. Обикновено внедряване, автотестове и т.н. Всички тези модни думи като Docker са неговият инструментариум.
- Site Reliability Engineer - инженер, който поддържа операции (надстройки, хардуерни разширения)
- Configuration Manager - непонятна за мен специалност. Ужасен продукт на HR-специалисти, оказващи натиск върху гръмкото име на позицията. Човек може да отиде по-далеч и да нарече специалността ZooKeeper вицепрезидент
Почти винаги всички тези роли се комбинират от един или двама души. Ами зависи от качеството на кода. Нека накратко наречем тази компания BRAE/CM. Задачата на BRAE/CM е да гарантира, че програмният код, който излиза от писалката на програмистите, остава под контрола на програмисти и системни администратори едновременно.Разработчиците, както и системните администратори, благодарение на подхода DevOps, имат възможността и дори задължението да поддържат кода през целия жизнен цикъл от планирането на архитектурата до кошчето. Тоест системните администратори започват да управляват дори преди кодът да стигне до тях - в ранните етапи, а програмистите продължават да управляват задачите си, след като кодът е преминал от тях към системните администратори - в по-късните етапи. И всичко това е прозрачно един за друг и всички проблеми и решения се въртят напред-назад и не се препъват в бюрокрацията в стил „нищо не знам, вече сме ангажирали кода, аз имам свои проблеми тук, те се счупиха - нека се оправят сами“.
Така че тази работа е последният етап на системния администратор и началният етап на разработчика. Следователно няма Junior BRAE / CM. BRAE/CM винаги е старши по системна администрация и винаги младши по програмиране.
Още един момент. У дома можете да научите инструментите на основно ниво. Но без готвене в една тенджера с истински разработчици смисълът на цялата тази кухня не може да бъде разбран. Така че ударете го веднага. Но ако искате, мога да опиша стъпка по стъпка дълъг път как да станете RE/CM:
Веднага ще говоря за езиците. Всеки език има своя собствена цел. Java се използва по-често в корпоративния сектор. Има много сървъри и сложни бизнес приложения. Следователно светът на Java е много чувствителен към понятия като "технически дълг" и "управление на процеса на разработка". И затова там са всички основни свободни позиции в DevOps и там ще бъде най-интересното преживяване. Освен Java, Ruby има традиционно силна DevOps култура. Почти всички други езици нямат толкова развита и популярна инфраструктура в този контекст и следователно е вероятно да не се интересувате. С други думи, ако изборът на език в средата за разработчици- тема за holivar и емоции с милиони сравнителни анализи с противоположни резултати, тогава за DevOps специалистите изборът е очевиден и прозрачен. Java е в същото време най-интересните задачи, най-богатият набор от инструменти, най-големият избор на свободни позиции и най-високите заплати.
Всеки следващ параграф, с изключение на особено дългия първи, ще доведе до седмица или две доста плътна работа. Ако не отлагате и отделяте няколко часа вечер.
И така, какво да направите: 1) Четете Head First Java книги. Вземете курсове по Java на EDX. 2) Научете SVN. Има отлични уроци. (GIT ще бъде усвоен по-късно) 3) Инсталирайте VirtualBox (не VMWare. ) 4) Напишете просто приложение. Задайте кода към SVN. Изградете го с maven. 5) Стартирайте на отделна виртуална машина Jenkins. Той трябва да вземе кода на приложението на SVN и да стартира своя локален maven за изграждане. 6) Напишете модулни тестове за вашия код. Нека мейвън да ги изгони и тях. 7) Вземете Nexus някъде. Направете по-трудно за maven, така че сега да постави всичко в Nexus. Ако maven се нуждае от външни библиотеки, той също не трябва да отива в самия интернет, а през Nexus (Централно репо). 8) Настройте vagrant на вашия работен плот, така че да създава виртуални машини VirtualBox от нулата. 9) Създайте DEV VM с помощта на vagrant. В същото време ansible трябва да конфигурира нещо върху него (например да инсталира JDK) 10) Научете как да разположите jar / war от Nexus към виртуалната машина DEV с нещо. Какво няма да посъветвам, тъй като самият аз работя с много сложен IBM uDeploy и това определено не е за начинаещ. Погледнете към Rundeck или нещо подобно. Може би го внедрите сами с Дженкинс. 11) Напишете интеграционни АВТОтестове. На каквото искаш (като опция: Селен).
Ние усложняваме системата. 12) Персонализиране на Jenkins:изгражда maven проект; качвания в Nexus; изтегля vagrant / ansible за създаване на виртуален SIT (тест за системна интеграция); внедрите приложението в SIT; изпълнява автотестове на SIT; премахва виртуалната машина след успешно завършване на автотестовете. 13) Закрепваме SonarQube в Jenkins за анализ на статичен код. Поправяме задръстванията на нашия код, според препоръките, получени от SQ. 14) Закрепете наблюдението на Sensu. 15) Пишем тестове за натоварване на нещо. В идеалния случай докоснете два инструмента: jMeter и Gatling. 16) Както в 12-та стъпка, ние закрепваме в Jenkins автоматизацията за създаване на виртуална машина SLT (Stress/Load test) и провеждане на тестове върху нея. Само тестове за натоварване (задължителни) и стрес тестове (по избор). 17) Добавяме някои функции към нашето приложение, така че да се използва основата. 18) Ще трябва да опознаете LiquiBase. Ръчното внедряване на SQL е забранено. 19) Преминете към Docker (т.е. сега приложението не е разположено директно в операционната система, а вътре в докера)
20) Ден за четене за Agile, Scrum, Waterfall и други организационни практики.
А сега нека навлезем малко в управлението на проекти: 21) Инсталирайте Atlassian Jira. Разберете разликата между Epic, Story, Task, Sub-Task. Създайте фронт на работа, подобен на тази структура (не е нужно да го правите, просто фантазирайте). 22) Инсталирайте Atlassian Stash и го свържете с Jira. 23) Преминете от вашия SVN към GIT, предоставен от Stash. 24) Прегледайте някой урок по Git. Инструментът е много нетривиален. 25) Вземете всяка задача на работа. В същото време, в началото на работата, направете нов Git клон от билета Jira. 26) След завършване на работата стартирайте цялата верига, изградена по-рано, но за вашия клон. Нека позная: трябваше да копирате всички задачи ипренаписване на клонове в тях? 27) Вършете работа нормално. Така че едни и същи да могат да се използват за всякакви клонове - по аналогия с програмния принцип "повторно използване на кода". Ще имате работа за повторно използване :) 28) Направете заявка за изтегляне, направете сами преглед на кода и се самоодобрете. След това обединете вашия клон в master. 29) Направете автоматично изграждане на клонове чрез git-hook (или SCM пул)
30) А сега висш пилотаж: по дяволите с Докер, Копистрано и прочие модни думи-хипстъри-глупости. Вече сте запознати с това и можете да го приложите, но е време да изгризате тази детска градина с нажежено желязо. Сега доставяте код само като .deb пакети. Това означава, че вие: a) разделяте контролния файл на множество пакети, евентуално с lib*, b) заменяте всичко
20 dh_ във файла с правила, така че всичко да съответства на работата ви в предишните параграфи. c) разпръснете файлове върху .install d) най-трудната част: подгответе .preinst, .postinst, .prerm, .postrm файлове СПОРЕД ТЕХНИТЕ ПРИМЕРИ .ex, генерирани от dh_make - тоест разбити на update/configure/broken-install и какво ли още не. Това означава, че при повторно инсталиране, при надграждане, при понижаване, при деинсталиране и при изчистване ще имате различни сценарии, всеки от които трябва да бъде обработен внимателно. На този етап ще се запознаете и с понятието "регресионни тестове".
Е, ето основната версия. Но това не е целият набор от инструменти и начин. Точно така, като за начало. Освен това би било хубаво да се запознаете с Puppet (той не е много подходящ за DevOps, по-скоро за обикновени администратори с куп сървъри, но това е много популярен инструмент, защото никой не разбира какво е DevOps и най-вероятно ще бъдете принудени да управлявате стотици сървъри вместо инженеринг на версии). Освен това трябва да опознаетес операционни системи NixOS (задължително) и CentOS / Debian (по избор, но бих победил тези, които не познават тези ОС с пръчка). Освен това трябва да имате основни познания за PostgreSQL.
Внимание, важен момент, който трябва да бъде зашит в подсъзнателното ниво на инженер, ориентиран към DevOps: вие опитвате нови инструменти през цялото време. Винаги ще намерите нещо много различно. Познавате ли Nexus като петте си пръста и той решава почти всички проблеми? Страхотен! Сега изхвърлете Nexus и инсталирайте Artifactory. Познавате ли CentOS добре? Готино! Сега опитайте да направите всичко това на Windows или Debian. Защото само когато можете да сравнявате инструменти, вашата работа ще бъде бижу. А DevOps или е бижу, или не е DevOps. Трябва да сте независими от езика, платформата и инструмента.
Какво ще се случи след това? След това ще започнете да работите с микроуслуги (стотици идентични контейнери в облака, които по някакъв начин трябва да работят един с друг без ръчна конфигурация). След това се запознайте с всички видове Consul, ZooKepper и куп AWS / OpenStack инструменти.