Download presentation
Presentation is loading. Please wait.
Published byGervase Bell Modified over 6 years ago
1
An introduction to immutable infrastructure using Azure DevOps pipelines
Ibon Landa Luis Fraile #DevSum19
2
Don’t forget to evaluate this session in the DevSum app!
3
Ibon Landa LF @ibonilm
4
Luis Fraile @lfraile lfraile@plainconcepts.com IL
Luis has been working around software development for more than ten years. Involving development, analysis, team magement, etc. Luis helps teams to be more effective in their development teams with tools like best practices and agile methodologies. Also he loves to be involved in the creation and developing all aspects of software products with proven experience during my career. B!Play marketing platform based on digital content @lfraile
5
Our team IL We provide full development and design of digital products from start to finish as well as consulting services as requested. We craft innovative and engaging custom solutions for our partners. That includes multi-platform applications, cloud services, customized backend solutions, desktop clients as well as public and private web portals.
6
Where to find us IL
8
Agenda DevOps Intro Inmutable infrastructure Infrastructure as a Code
Azure DevOps pipelines Inmutable infrastructure with Docker Inmutable infrastructure with Virtual Machines LF
9
S4 Solution Specialist Sales Summit
6/17/ :28 AM “DevOps is development and operations collaboration” “DevOps is treating your infrastructure as code” It’s DevOps! LF It’s DevOps! “DevOps is using automation” “DevOps is feature switches” It’s DevOps! It’s DevOps! © 2013 Microsoft Corporation. All rights reserved. Microsoft, Windows, and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries. The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION. “Scrum for Ops?” “DevOps is small deployments”
10
What is DevOps? People. Process. Products. Build& Test Deploy DevOps is the union of people, process, and products to enable continuous delivery of value to your end users. Donovan Brown (Microsoft) “ ” LF DevOps is the union of people, process and products to enable the continuous delivery of value to your end customers Continuous Delivery Develop Operate Plan & Track Monitor & Learn
11
DevOps Best Practices Version everything Automate everything
Course or module title Date or rev # DevOps Best Practices Version everything Automate everything Tokenize configurations Use one-click deployments Deploy the same way to every environment Have always a rollback mechanism in place Build only once Lock down the environments … IL DevOps is a journey and there are couple of DevOps best practices that can help your teams to walk this path These best practices go beyond common sense; they get at the essence of what DevOps means for your enterprise and how to get DevOps right the first time. Version everything Do you exclude from versioning artifacts like databases, configuration files, binaries, documentation, tools or environments? To determine whether you're versioning everything, the simple question to ask is, "Can I recreate a specific version of the complete software system — with servers, environments, data, software, and configuration — by running one command that gets a specific revision from my version-control system?" If you cannot, you're not versioning everything. Tokenize configurations Do you manually copy or change configuration files to match each target environment? So… Do you need to remember which configuration files must be changed Do you make mistakes or omissions when doing these changes? Are you exposing sensitive information about the environments? Only build packages once. We want to be sure the thing we’re deploying is the same thing we’ve tested throughout the deployment pipeline, so if a deployment fails we can eliminate the packages as the source of the failure. Deploy into a Production-like Environment Forget last-minute surprises!! They can be eliminated and applications can be released safely to production at any time….you test your application that then you deploy it in another enviroments that it´s different, it doesn´t make sense! Each new deployment should be made into an environment very similar to the actual final production environment. HP Confidential – For training purposes only
12
Infrastructure
13
Infrastructure can be complex
LF Las apps/infra cambian Las apps/infra evolucionan Puede haber múltiples entornos que tiene que ser iguales
14
A regular deployment pipeline
15
A regular deployment pipeline
To produce a release, we need to build it from source The resulting application deliverable app is… a single immutable unit built once and stored in an artifact repository regenerated by the continuous integration system after every change IL Let's assume we have an application. To produce a deliverable, we need to build it from source. This involves compiling sources, processing and copying resources, and probably a few more steps. In its simplest form this process looks like this: The resulting application deliverable (typically a .jar or .war file for JVM-based apps) isa single immutable unit built once and stored in an artifact repository regenerated by the continuous integration system after every change
16
A regular deployment pipeline
Of couse, it requires a stack of software to execute… Server application Language runtime Libraries OS … IL The application of course doesn't run directly on bare metal. Whether on your laptop or on a server, it requires a stack of software to execute. A typical server application requires an app server (embedded in the app or not) and a language runtime (like the JVM). The language runtime itself uses various libraries and runs on top of an OS kernel which drives the hardware.
17
A regular deployment pipeline
There are several machines the app needs to run The application is gradually promoted from env to env The same app is pulled from the artifact repository IL In all but the simplest projects, there are several machines the application needs to run on, organized in multiple environments. The application is gradually promoted from environment to environment. This ensures that what is run in production, is what was tested in test. To achieve this, the same application is pulled from the artifact repository and deployed unchanged to the different machines: This avoids the classic mistake of building a separate artifact per environment and effectively taking the risk of running something potentially different on all machines. Yet when we look at the remaining layers of our stack, this is exactly what is happening!
18
A regular deployment pipeline
The job of the system administrator to ensure that these machines are as identical as possible All changes, patches and upgrades need to be performed on all machines IL It is the job of the system administrator to ensure that these machines are as identical as possible, yet each is built individually. All changes, patches and upgrades need to be performed on all machines. The sheer complexity of this task and the numerous moving parts make this very difficult to achieve reliably. Even with automated configuration tools and recipes it's easy for some minor detail to slip through the cracks! So what could potentially go wrong?
19
But sometimes…The system becomes a house of cards
Some additional software is missing A resource (directory, ...) has been created under the wrong name The wrong version of some software is installed Permissions have been set incorrectly a critical resource (port, ...) is occupied Application code is deployed outside of the normal straight-from-source-control process The operating system has been patched again and again …. IL & LF completa Here is just of short list of issues, most of which you will probably already have encountered: some additional software is missing a resource (directory, ...) has been created under the wrong name the wrong version of some software is installed (usually the old one with the bug) permissions have been set incorrectly a critical resource (port, ...) is occupied If these are the risks, then why aren't we holding our systems to the same standards as our applications by applying the same principles for building them? Why are we still building works of art and snowflake servers when what we need is an army of clones?
20
At the end of the day …
21
Immutable Infrastructure
The whole machine is now packaged as a single immutable unit It contains the entire software stack and it is regenerated by the continuous integration server after every change LF This is where Immutable Infrastructure comes in. Instead of assembling just the application, the whole machine is now packaged as a single immutable unit. It contains the entire software stack and it is regenerated by the continuous integration server after every change: Instead of having to worry about updating many moving parts at all layers, the whole Machine Image is now promoted unchanged from Environment to Environment. Effectively finally making sure that what we run in production is what we tested in test.
22
Immutable Infrastructure
23
What is Immutable Infrastructure
Immutable infrastructure is comprised of immutable components that are replaced for every deployment, rather than being updated in-place. Those components are started from a common image that is built once per deployment and can be tested and validated IL Immutable simply means something that is created and left unchanged. it means is that once the image is working, only a working image is deployed
24
Advantages Reduce inconsistency in your infrastructure
It is easy to have a production-like system on development machines Improve the trust into your deployment process Rollback to an old version is easy Every change is in a script Setting up staging systems is easy and can be automated Testing the new infrastructure in isolation is possible LF
25
We also need tools!
26
IL As we spoke before You can’t buy DevOps, as DevOps is not a software, tool, process, company, or person — it’s a methodology. There are, however, products & tools that can help enable different DevOps practices and different teams which can be used to make things easier. DevOps is not a tool or a software, it’s a culture that you can adopt for continuous improvement. It will help you to bring your Developer Team and Operations Team on the same page, allowing them to work together with ease.
27
IL
28
Just our tooling… Microsoft Azure Azure DevOps pipelines Terraform
Docker Ansible Packer … IL
29
Azure DevOps pipelines
30
Introducing Azure DevOps
Azure Boards Azure Pipelines Azure Repos LF Deliver value to your users faster using proven agile tools to plan, track, and discuss work across your teams. Build, test, and deploy with CI/CD that works with any language, platform, and cloud. Connect to GitHub or any other Git provider and deploy continuously. Get unlimited, cloud-hosted private Git repos and collaborate to build better code with pull requests and advanced file management. Azure Test Plans Azure Artifacts Test and ship with confidence using manual and exploratory testing tools. Create, host, and share packages with your team, and add artifacts to your CI/CD pipelines with a single click.
31
Azure Pipelines Cloud-hosted pipelines for Linux, Windows and macOS, with unlimited minutes for open source Any language, any platform, any cloud Build, test, and deploy Node.js, Python,
Java, PHP, Ruby, C/C++, .NET, Android, and iOS apps. Run in parallel on Linux, macOS, and Windows. Deploy to Azure, AWS, GCP or on-premises LF Extensible Explore and implement a wide range of community-built build, test, and deployment tasks, along with hundreds of extensions from Slack to SonarCloud. Support for YAML, reporting and more Containers and Kubernetes Easily build and push images to container registries like Docker Hub and Azure Container Registry. Deploy containers to individual hosts or Kubernetes. Best-in-class for open source Ensure fast continuous integration/continuous delivery (CI/CD) pipelines for every open source project. Get unlimited build minutes for all open source projects with up to 10 free parallel jobs across Linux, macOS and Windows
32
Demo LF (5 mins) YAML Build artifacts Agents Trigger
Build one => poner foco 1 build & N pipelines Variables de release Demo
33
Infrastructure as code
34
Infrastructure as code
Course or module title Date or rev # Infrastructure as code Infrastructure IT infrastructure consists of all components that somehow play a role in overall IT and IT-enabled operations. It can be used for internal business operations or developing customer IT or business solutions. Code A set of instructions or statements that are processed by a computer. Infrastructure as code Treating your infrastructure as code to ensure that is as versionable, repeatable, and testable as application code IL So….automate your environments!! The environment for your application is typically made up of many components – maybe a virtual machine, storage account, and virtual network, or a web app, database, database server, and 3rd party services….whatever.. Iac/Terraform enables you to work with the resources in your solution as a group. You can deploy, update, or delete all the resources for your solution in a single, coordinated operation. You use a template for deployment and that template can work for different environments such as testing, staging, and production. So creating a template we can version it as any other artifact of the project……do you remember? Version everything! So it´s very easy to create the required environment at any time and of course by anyone. HP Confidential – For training purposes only
35
Benefits Avoid deployment inconsistencies Speed and simplicity
Configuration consistency Minimization of risk Increased efficiency in software development Cost savings IL
36
What is Terraform A tool for… “Write, Plan, and Create Infrastructure as Code” Open Source, created by Hashicorp (vagrant, packer…) A tool to manage virtual server life cycles (AWS, Azure, VMWare, OpenStack, Google cloud, Heroku, Kubernetes etc…) A tool to manage supporting services (DNS, ..) Readable and writable Written in Go Pluggable Multiplatform LF
37
Resources (Azure) resource "azurerm_resource_group" "test" {
name = "example-resources" location = "West Europe" } resource "azurerm_app_service_plan" "test" { name = "example-appserviceplan" location = "${azurerm_resource_group.test.location}" resource_group_name = "${azurerm_resource_group.test.name}" sku { tier = "Standard" size = "S1" resource "azurerm_app_service" "test" { name = "example-app-service“ // Globally unique name here!! app_service_plan_id = "${azurerm_app_service_plan.test.id}" LF
38
Resources (Amazon) resource "aws_elastic_beanstalk_application" "tftest" { name = "tf-test-name" description = "tf-test-desc" } resource "aws_elastic_beanstalk_environment" "tfenvtest" { name = "tf-test-name" application = "${aws_elastic_beanstalk_application.tftest.name}" solution_stack_name = "64bit Amazon Linux v4.8.1 running Node.js" LF
39
LF Enseñar repo/artefacto/tarea de release. Demo
40
Immutable Infrastructure with Docker
41
Immutable infrastructure with Docker
IL
42
Version everything!! LF
43
Build & Publish docker images to ACR
LF
44
Deploy to several environments
45
Deploy the same artifacts / the same way
46
IL Demo
47
Immutable Infrastructure with Virtual Machines
48
Ansible, Packer & Terraform
LF
49
Packer Packer is a tool for creating machine and container images for multiple platforms from a single source configuration IL Packer & Azure Easy to automate the creation of custom images Installs and configures software at build time Single config file to create custom images Support for multiple platforms Embraces modern configuration management And more…
50
Packer Template IL
51
Immutable infrastructure
IL DevOps commit code or configuration change VSTS Build builds and packages application VSTS Release invokes Packer to build a Linux image and store it in Managed Disks Packer invokes the Ansible Playbook provisioner to install JDK, Tomcat and SpringBoot application VSTS Release invokes Terraform to provision Infrastructure and uses Packer build image
52
Continuous integration build definitions
Apply the configuration using Ansible Create the images using Packer templates Publish generated images IL
53
Deploy to several environments
Apply the configuration using Ansible Create the images using Packer templates Publish generated images IL
55
And…. Last but not least – don’t forget to evaluate this session in the DevSum app!
57
Where to find us
Similar presentations
© 2025 SlidePlayer.com Inc.
All rights reserved.