Introduction to DevOps
Download as PPTX, PDF6 likes3,112 views
This document provides an introduction to infrastructure as code and DevOps. It discusses how infrastructure complexity has increased over time from mainframes to multi-tier applications to cloud computing. It also covers how separate development and operations teams can be merged into a unified DevOps team. Infrastructure as code is introduced as treating infrastructure like code by automating server provisioning, configuration, and changes using tools like Puppet, allowing infrastructure to be version controlled and changes to be tested. This enables continuous delivery of infrastructure updates alongside application code changes.
![Puppet manifests
package { "openssh":
ensure => present,
}
service { "sshd":
ensure => running,
hasstatus => true,
hasrestart => true,
enable => true,
require => Package["openssh"],
}](https://image.slidesharecdn.com/introductiontodevops-130314081441-phpapp01/85/Introduction-to-DevOps-48-320.jpg)
![Puppet templates
package { "openssh":
ensure => present, Port <%= listen_port%>
} Protocol 2
SyslogFacility AUTHPRIV
service { "sshd": PermitRootLogin no
ensure => running, PasswordAuthentication no
hasstatus => true, ChallengeResponseAuthentication no
hasrestart => true, GSSAPIAuthentication yes
enable => true, GSSAPICleanupCredentials yes
require => Package["openssh"], UsePAM yes
} X11Forwarding yes
Banner /etc/motd
$listen_port=2222
sshd_config.erb
file { "/etc/ssh/sshd_config":
path => "/etc/ssh/sshd_config",
owner => root,
group => root,
mode => 444,
content => teplate("sshdconf/sshd_config.erb"),
notify => Service[sshd],
}](https://image.slidesharecdn.com/introductiontodevops-130314081441-phpapp01/85/Introduction-to-DevOps-49-320.jpg)
Introduction to DevOps
- 1. Infrastructure as Code Introduction to DevOps and nfrastructure As Code Infrastructure as Code Rolands Mekšs A/S 4finance Infrastructure as Code
- 2. Infrastructure Complexity < 80s Mainframes
- 3. Infrastructure Complexity < 80s 80s - 90s Mainframes Client Server
- 4. Infrastructure Complexity < 80s 80s - 90s 90s Mainframes Client Multi-Tier apps Server
- 5. Infrastructure Complexity < 80s 80s - 90s 90s 2000s Mainframes Client Multi-Tier apps Data Centers Server
- 6. Infrastructure Complexity in 2010s Cloud Provider Client Data Center Internet
- 7. Infrastructure Complexity Virtual Nodes Physical Hardware
- 8. Concept of physical hardware blurs
- 9. Everything as a Service
- 11. Soon will hit 100 production server count (DB/Application/Web Proxies) Not counting testing / staging / UAT / DR environments
- 12. Agile development Quick reaction to requirements and change Short development sprints Develop small, incremental releases Continuous integration Continious delivery of working software
- 13. Agile software delivery Deploy Risk Develop Deploy Risk Develop Time
- 14. Continuous delivery Deploy Risk Develop Deploy Risk Develop Deploy Risk Develop Deploy Risk Develop Time Challenging if not impossible without serious CI, testing and automated deployments
- 15. Separate teams Development Operations
- 16. Separate teams Development Operations We want change
- 17. Separate teams, distinct goals Development Operations We want change The answer is NO
- 18. Wall of confusion Development Operations We want change The answer is NO
- 19. Merge of concerns DevOps
- 20. What is DevOps More like an idea or collaborative culture/philosophy between technical teams Often stated as «Agile for Operations» Unified processes, unified tools for faster end-to-end delivery of quality software Automate all the things! Not a job description, same way as there is no such job «Agile Developer» It’s just a way of work
- 21. DevOps team in 4finance Provide teams with processes and tools for better day to day project activities Automate environment creation Enable automated deployment process Enable freely available performance monitoring and log viewing Provide support in infrastrucure related questions Enable DevOps
- 23. How do you provision new server? Adhoc actions – hack while it works
- 24. How do you provision new server? Adhoc actions – hack while it works SNOWFLAKES ARE SPECIAL, SERVERS ARE NOT
- 25. How do you provision new server? Follow some documented instructions
- 26. Doing changes to servers manually involves PEOPLE
- 27. Doing changes to servers manually involves PEOPLE Terrible of doing things repeatedly
- 28. Doing changes to servers manually involves PEOPLE Terrible of doing things repeatedly
- 29. More than80% of all mission-critical IT service outages are due to PEOPLE and process errors
- 30. How do you provision new server? Use self written shell scripts + Some sort of automation + Version control possible + Works fine if you have 5 or so servers
- 31. How do you provision new server? Use self written shell scripts + Some sort of automation + Version control possible + Works fine if you have 5 or so servers - Does not handle change during server lifecycle
- 32. True story Simple change as timezone setting Options: • Log in each affected server and change manually • SSH for loop could do the trick
- 33. True story Simple change as timezone setting Options: • Log in each affected server and change manually • SSH for loop could do the trick Configuration drift!
- 34. There got to be better way
- 35. We know how to handle change in software development Code and configuration is in verison control system Unit and integration tests Safe acceptance testing in test/stage environments Code review
- 36. Infrastructure should be treated like a code Packages installed, versions Server and application configuration (such as timezone settings) Relationships with other servers and services
- 37. Infrastructure should be treated like a code Packages installed, versions Server and application configuration (such as timezone settings) Relationships with other servers and services We want Automated , repeatable operations Predictable outcome Remove manual, error prone steps Manage change during server lifecycle Ability to test outcomes
- 38. Infrastructure as Code "Enable the reconstruction of the business from nothing but a source code repository, an application data backup, and bare metal resources" Adam Jacob
- 40. Configuration management Declarative specifications or policies Setting the Policy Report Executing the policy the policy Auditing the policy
- 42. How Puppet Works Manage infrastructure throughout its lifecycle
- 43. Puppet Resources Resources – Puppet building blocks user { 'dave': ensure => present, uid => '507', gid => 'admin', shell => '/bin/zsh', home => '/home/dave', }
- 44. Resources – Puppet building blocks package { 'apache2': ensure=>'installed' }
- 45. Resources – Puppet building blocks package { 'apache2': ensure=>'installed' } service { 'apache2': ensure=>'running' }
- 46. Resources – Puppet building blocks package { 'apache2': ensure=>'installed' } service { 'apache2': ensure=>'running' } cron { cleanup: command=>'/test/cleanup.sh', user=>test, hour=>5, minute=>0 }
- 47. Resources – Puppet building blocks package { 'apache2': ensure=>'installed' } service { 'apache2': ensure=>'running' } cron { cleanup: command=>'/test/cleanup.sh', user=>test, hour=>5, file { ‘/tmp/helloPuppet': minute=>0 content=>‘Hello!' } }
- 48. Puppet manifests package { "openssh": ensure => present, } service { "sshd": ensure => running, hasstatus => true, hasrestart => true, enable => true, require => Package["openssh"], }
- 49. Puppet templates package { "openssh": ensure => present, Port <%= listen_port%> } Protocol 2 SyslogFacility AUTHPRIV service { "sshd": PermitRootLogin no ensure => running, PasswordAuthentication no hasstatus => true, ChallengeResponseAuthentication no hasrestart => true, GSSAPIAuthentication yes enable => true, GSSAPICleanupCredentials yes require => Package["openssh"], UsePAM yes } X11Forwarding yes Banner /etc/motd $listen_port=2222 sshd_config.erb file { "/etc/ssh/sshd_config": path => "/etc/ssh/sshd_config", owner => root, group => root, mode => 444, content => teplate("sshdconf/sshd_config.erb"), notify => Service[sshd], }
- 51. How Puppet Enforces Desired State
- 52. Node definitions in Puppet node base { node { ‘my.prod.server.com’ inherits base include openssh include mymanifest.pp $apacheversion = "2.0.33" } package { "apache2": ensure => $apacheversion, } }
- 53. Development practices applied to infrastructure Version control & source code management IDEs, editors, refactoring tools Environments Self-documentation Testing
- 54. BDD with Puppet
- 55. Puppet development with Vagrant A tool for building virtualized environments in your PC Actually works as command line wrapper for VirutalBox Shared filesystem between host and guest Allows to spin up virtual machine with preinstalled Puppet/Chef
- 57. Vagrant – boxes and environments $ vagrant box add lucid32 http://files.vagrantup.com Vagrant::Config.run do |config| # Setup the box config.vm.box = "lucid32" config.vm.provision :puppet do |puppet| puppet.module_path = "puppet/modules" puppet.manifests_path = "puppet/manifests" end end
- 58. Vagrant – boxes and environments $ vagrant up $ vagrant provision $ vagrant ssh $ vagrant destroy
- 59. Modeling environment systems with Vagrant
- 60. Q&A
Editor's Notes
- #2: Prezentācija divās daļās, Vienā skaidrojums par DevOps un esošajiem izaicinājumiemOtrā – Infrastructure as code, Configuration management un intro to Puppet
- #7: Viens no mūsdienu izaicinājumiem - aplikāciju deployment sarežģītība šādā vidēKatrai komponentei ir kādi savi deployment likumi, atkarības no citām komponentēmPievienojiet visam šim OS konfigurācijas, direktoriju struktūras, maintenance, security prasības, integrācijas ar ārējiem servisiem utt
- #9: Fiziska hardware koncepts izplūst, ar fiziskām iekārtām mūsdienās lielākoties saskaras tikai datu centru operations cilvēki.Vmware, kuru mēs visi pazīstam kā vienu no vadošajiem virtuālās infrastruktūras ražotājiem, to lieliski parāda savā prezentācijas materiālāVirs dzelžiem faktiski tiek uzbūvēts jauns abstrakcijas līmenis – «Virtuālā infrastruktūra»Mēs visi zinam cik viegli ir dabūt strādājošu mašīnu AWS, Rackspace vai citā coludā. API izsaukumi.Viss ir kļuvis par software.
- #10: Katru dienu katrs no mums saskaras ar kaut kādiem mākoņservisiemŠodien viss ir savstarpēji saslēdzams, visam ir savs API, kas ļauj sadarboties ar citām sistēmām, viss ir būvēts uz kādas no XaaS platformām.Even infrastructure teams are speaking in terms of virtual servers, virtual routers, virutal switches, virutal ethernet cards, virtual desktops, virtual <insert your piece of hardware here>Viss ir kā serviss
- #11: This pal of mine thinks that clouds are really made of ... clouds.
- #12: Daži fakti par infrastruktūruServeru skaits nopietni prasa pēc kaut kāda labāka risinājuma
- #14: Iteartīvais process – develop/deployJo lielākas iterācijas, jo lielāks risks
- #15: Software delivery may be agile and fast but it creates bottlenecks at QA gateway and Operations, because they are NOT agile and requires quite a lot of manual work
- #16: Development team – development, build, integrate, QA, software releaseOperations team – system administration, provisioning, configuration, health monitoring, change/release management
- #20: Veidot tādu kulturālu vidi kurā visi strādā pie viena mērķa, kur nav sienu pār kurām tiek mētātas atbildības.Panākt lai komandas var patstāvīgi veikt lielāko daļu daļu darba, kas sevī ietver pilnu ciklu no izstrādes līdz deployment produkcijā. Tajā pašā laikā nenolaužot kaklu infrastruktūras sarežģītībā
- #21: Automation that accelerates release times, eliminates manual work, reduces errors
- #22: Izrietot no iepriekšminētā, vispirms jāsaka, kas DevOps komanda nav – mūsu mērķis nav kļūt par atsevišķu web-operations administratoru komanduBet gan nodrošināt komandas ar vienotiem procesiem un rīkiem ar kuriem viņas pašas varētu veikt lielāko daļu ikdienas darbu, kas saistītas ar projekta dzīves cikla uzturēšanuMēs gribam nodrošināt komandas ar iespēju pašām būt saimniekiem saviem projektiem, ērti deployot produktu versijas, veikt konfigurācijas izmaiņas, monitorēt aplikācijas un pārvaldīt logus, ja vajag – modelēt aplikācijas izolētās virtuālās vidēs.
- #24: Esam piereģistrējamies X cloudā, izveidojam jaunas servera instancesGoogle, how to set up Postgres, Java, Tomcat, Apache.Pēc tam liekam savu aplikāciju, rediģējam konfigurācijas failus, skatamies kas neiet, kas iet, līdz viss strādā
- #25: Serveri kļūst kā sniegpārsliņas, ārēji līdzīgi, bet divus vienādus neatrastTā tas nedrīkst būt, serveru instalācija un konfigurācija nav un nedrīkst būt mākslaTam ir jābūt formālam, un pilnībā atkārtojamam procesamVisiem web serveriem jābūt instalētām vienām un Tām pašām pakotnēm, Tām pašām aplikāciju versijām, Jādarbojas tiem pašiem likumiem, un procesiem
- #26: Projekts aug, esam kļuvuši gudrāki, esam izveidojuši instalācijas un konfigurācijas dokumentāciju wiki lapāTagad process ir dokumentēts un atkārtojamsJaunu serveri varam sagatavot dienas laikā!Taču joprojām
- #27: Manuālu serveru instalēšanu un konfigurēšanu veic cilvēks
- #28: Cilvēkiem ļoti slikti padodas rutiniskas, atkārtotas darbībasCilvēks noteikti kādā momentā zaudējot uzmanību kļūdīsies
- #29: Kā arī – cilvēki ir lēni
- #31: Projekts aug, mums ir 50 serveri, esam kļuvuši gudrāki, tagad mums ir shell skripti.Ievērojami labāks risinājums par dokumentāciju, kuras gadījumā jāuztur ne tikai konfigurācija, bet arī dokumentācijaShell skriptus var turēt versiju kontroles sistēmāShell skripti strādā arī daudz lielāku serveru skaitu
- #32: Skripti pamatā darbojas tikai servera dzīves cikla sākumā, taču tie nepalīdz ar izmaiņām, kas noteikti būs. Ar šo patiesību mēs praktiski saskārāmies arī savā darbībā 4finance, kad sapratām, Šīs prakses vairs efektīvi nedarbojas pie mūsu mērogiem un attīstības tempiemMums bija izrtrādāti un joprojām lietojam labus shell skriptus ar kuriem mēs varam salīdzinoši ātri sagatavot jaunus serverusTie pat ir kustomizēti dažādām vidēm, test/stage dažādi parametriBet lielākās problēmas sagādā tieši izmaiņas dzīves ciklā un fakts, ka trūkst kaut kādas centralizētas konfigurācijas vadības
- #33: Daži fakti par infrastruktūruŠobrīd visa mūsu biznesa kritiskā infrastruktūra ir izvietota Rackspace cloudā99,95% piejamība, kas ir OK priekš mums, downtime galvenokārt dēļ kaut kādām infra problēmām, kuras risina galvenokārt Rackspace speciālisti.Serveru skaits nopietni prasa pēc kaut kāda labāka risinājuma
- #34: Logoties katrā serverī un manuāli mainīt laika zonu uzstādījumus.
- #35: Logoties katrā serverī un manuāli mainīt laika zonu uzstādījumus.Konfigurācijas peldēšana, manuālas novirzes no sākotnējās konfigurācijas
- #37: Mēs zinām kā pārvaldīt izmaiņas programmatūras izstrādēBūtu labi, ja arī infrastruktūrā mēs varētu tikpat paredzami veikt izmaiņas un būt par tām pārliecināti
- #38: Infrastruktūra būtu jāuztver kā kodsAprakstīt koda veidā instalējamās pakotnesServeru konfigurācijuSaiknes ar citiem serveriem
- #39: Infrastruktūra būtu jāuztver kā kodsAprakstīt koda veidā instalējamās pakotnesServeru konfigurācijuSaiknes ar citiem serveriem
- #40: Pašā dziļākajā būtībā, ideālais mērķis ir panākt tāda veida automatizāciju, ka, ja vienu dienu mūsu infrastruktūra kaut kāda iemesla pēc nav pieejama, mēs vienkārši citā datu centrā paceļam tādu pašu izmantojot tikai koda repozitoriju datu rezerves kopijas.
- #41: Netflix – pasaules lielākais interneta video streaming serviss.Viens no redzamākajiem automatizācijas piemēriem internetāAmazon AWS balstīts servissCik gudra doma ir ielaist pērtiķi serveru telpā?Tiks izrauti vadi, apgāztas kaut kādas iekārtas.Varbūt tas ir labi, mēs redzēsim, cik mūsu sistēma ir droša pret dažāda veida atteikumiemNetflix izstrādājuši analogu DR sistēmu pērtiķim, kura AWS cloudā izslēdz serveru instances.Izraisītas 65000 instanču problēmasDara regulāri un plānotiJa esam pārliecināti ka mūsu arhitektūra ir bojājumu piecietīga šodien, vai mēs varam būt droši ka tā tāda būs pēc mēnešaLabākā aizsardzība pret negaidītām problēmām ir iekulties problēmās biežiFail oftenLabāk sistēmu labot 10:00 pie kafijas krūzes nekā sestdien 3:00 un nezināt ko darīt.
- #42: Atbilde uz daudziem mūsu jautājumiem ir – konfigurācijas vadība.Jēdziens ir sastopams ļoti daudzās industrijās, taču galvenā ideja ir par specifikāciju vai solījumu un tā izpildi sistēmas dzīves cikla laikā
- #44: Configuration Management SistēmaPuppet ir IT automatizācijas programmatūra, kas ļauj vadīt infrastruktūru visā tās dzīves cikla laikā sākot no serveru instalēšanas un konfigurēšanas līdz nepārtrauktai sistēmas auditēšanai un izmaiņu vadībai.Mērogojama - 10 vai 1000 serveriGan open source, gan commercial versijasAr Puppet deklaratīvu valodu apraksta resursu grafu kas veido puppet moduļus. Šie moduļi definē infrastruktūru un tās vēlamo stāvokli – kā mēs gribam lai mūsu sistēma izskatās. Apraksta deklaratīvā veidā – nevis «kā» bet «ko».Puppet ļauj simulēt izmaiņas, neveicot reālas izmaiņasPuppet salīdzina sistēmas faktisko stāvokli ar definēto. Ja tas atšķiras, Puppet automātiski noved līdz aprakstītajam stāvoklim. Tādā veidā izslēdzot konfigurācijas peldēšanu. Puppet Dashboard – atksaites par konfigurācijas izmaiņām un sistēmas stāvokļiem
- #45: Šis ir viens no Puppet ķieģeļiem – resursa tips «user»Ja Puppet sistēmā mēs esam aprakstījuši, ka tādam un tādam serverim
- #52: No Puppet manifestiem tiek būvēti atkārtojami lietojami moduļi, kas paredzēti kāda konkrēta darba veikšanaiPiemēram Postgres modulis visticamāk prastu sistēmā uzlikt Postgres pakotnes, konfigurēt security pieejas tiesības, izveidot datubāzi, izveidot postgres lietotāju utt.Par laimi Pupet Labs uztur visiem pieejamu moduļu repozitoriju Puppet Forge, kas ir kā Marketplace, kurā jau ir atrodami moduļi prakstiski visām tipiskajām sistēmas konfigurācijas vajadzībām. Ja mums ir īpašas prasības, mēs varam būvēt moduļus paši vai modificēt esošos no Puppet Forge.
- #53: Puppet pasaulē serveri, kuriem gribam vadīt kofigurāciju tiek saukti par Node.Katrai nodei ir savi iebūvētie vai custom Fakti – hostname, OS, arhitektūra, IP adrese, etc. Katrā nodē ir instalēts Puppet aģents, kas sūta centrālajam Puppet Master serverim šo informāciju par seviIzmantojot šos faktus, Puppet Master serveris sagatavo Katalogu, jeb – detalizētus datus par to, kā šai nodei ir jābūt konfigurētai un aizsūta to atpakaļ Puppet AģentamPēc tam, kad aģents ir veicis visas nepieciešamās izmaiņas nodē, lai tā atbilstu sākotnējajai specifikācijai (vai vienkārši pēc simulēšanas noop modē), aģents aizsūta atpakaļ Puppet Masteram pilnu atskaiti par to kas tika darīts un rezultātiemAtskaites pēc tam ir pieejamas pēc atvērta API ārējām IT sistēmām, piemēram monotoringa, vai dažādiem dashboardiemŠo ciklu var atkārot atkal un atkal, defaultā pēc 30 minūtēm. Idempotency, dēļ deklaratīvā apraksta.
- #55: Environments – puppet ļauj definēt vides – priekš test vidēm varam definēt vienus parametrus, priekš prod citus
- #57: Vagrant ir neatsverams rīks Puppet izstrādē. Ļauj programmiski pacelt virtuālas VirtualBox vides izstrādātāja datorāIzmantojot VirtualBox iespēju šārēt folderus starp VM un izstrādātāja datoru, Vagrant gājuši tālāk, Vagrant virtuālajās mašīnās ir preinstalēts Puppet vai Chef un šārētajā direktorijā ir pieejami puppet moduļi un manifestiTas ļauj veikt puppet developmentu izstrādātāja mašīnā, viņam ērtā redaktorā vai IDEUn uzreiz pārbaudīt kodu virtuālajā mašīnā.
- #61: Ar Vagrant mēs varam modelēt serveru sistēmas paceļot un konfigurējot vairākas virtuālās mašīnas