Packer, Terraform & Jenkins - DevOpsBelfast March 2019
•Download as PPTX, PDF•
1 like•88 views
Tools & Techniques for building & testing AMIs using Packer, Terraform, Jenkins, InSpec & a lot of bash glue
Recommended
More Related Content
What's hot
What's hot (10)
Similar to Packer, Terraform & Jenkins - DevOpsBelfast March 2019
Similar to Packer, Terraform & Jenkins - DevOpsBelfast March 2019 (20)
Recently uploaded
Recently uploaded (20)
Packer, Terraform & Jenkins - DevOpsBelfast March 2019
- 1. Packer, Terraform & Jenkins IaC & CD for small stacks Simon McCartney Twitter: @simonmcc
- 6. Background: Isn’t this a solved problem?
- 9. What does the pipeline look like? •Simple master/!master path
- 10. Goal 1: Traceable Images • What was this image built from? • Project, branch, SHA, clean, dirty • Store it inside the image and externally via tags
- 11. Goal 2: Testable Images • Validate that an image is good • Chef’s InSpec for os/infra • App/Service specific testing
- 12. Goal 3: Self Contained POC • Monorepo FTW, single pipeline • Minimal Jenkins Plugins • Sanity wrappers for Terraform & Packer • Terraform for the app • Terraform for the build environment
- 13. Jenkins from day 1 •Write tools & wrappers that work by default in Jenkins, easy path for non-interactive use •Disposable Jenkins setup – no dirty clicking Jenkins Configuration as Code, Job DSL & Jenkinsfile, docker container for local experiments https://github.com/jenkins201/jenkins-container
- 14. Packer Wrapper – build.sh •Modeled on base & app AMI •Expose git SHA & clean/dirty state to packer for including in tags etc (‘cos CLI building should still be possible!) •Only build base/app AMI when necessary
- 15. tf-wrapper.sh •Terraform wrapper •Map git branch to terraform workspace •Map git branch to tfvars •Expose git branch & sha to aid tagging & building unique resources (RDS Instance etc)
- 16. tf-wrapper.sh •Configure terraform remote state render backend_config.tf AWS: create s3 bucket & DynamoDB Azure: create Resource Group & Storage Account
- 17. Demo
- 18. Tips •Watch out for account or globally unique resources (that’s why we expose branch & SHA1 to packer & terraform) •SHA1 for images in this POC is weak – it’s of a git object that “mostly” represents the image build source. •Jenkins aws-credentials & docker agent is broken :(
- 20. We’re hiring! SRE, Remote UK & EU
Editor's Notes
- Who are Axon – we’re a leading supplier of software & services to the blue light industry, also known as public safety, our first product was the Taser, something so good it became a verb, Taser continues to be an important product for us, but we also provide a Digital Evidence Management System that’s a key element to our body camera division, and that’s where I work, I’m an SRE at evidence.com, helping build & operate the platform that hosts our services all over the world, managing video footage and other evidential material for police forces and other blue light industries all over the world.
- If you google enough or have been going to infrastructure management conferences for a few years, it would be easy to think that VM image baking ios a solved problem, we’ve been talking about it for ages, there are tools that do some of the essentials, but in my opinion, there was still a lot left as an exercise for the student. I started a new job recently, and we have a infrastructure that’s state of the art for the year 2010, terraform for cloud based infrastructure, puppet & salt for long lived VMs configuration management, but this leads to pain & bad practices, like manually resizing VMs & editing the terraform to keep sync, adding VMs to cope with a demand spike is painful, removing them is even more painful, you've got puppet certs, manual DNS, discovery via hieradata, all solved problems in some way.
- Nope. Many of our services are moving to k8s managed containers, but not everything will, for good & bad reasons. There are also some environments & companies where they’re just not interested in the k8s & PaaS overhead, they just want somewhere better to run their LAMP stack apps that fits with their appetite for change.
- As my new work environment was a little cumbersome to innovate & iterate in, I decided to do a POC outside our internal constraints & came up with a model of a simple linux web app stack & concentrate on what tools I would need, what the Jenkins pipeline might look like if I wanted to build & test on a PR branch and deploy to production from master.
- Back to what triggered this in work, I was delighted when I found a GitHub repo in our org called ops/packer – yes I thought, somebody has already done the hard work, we had layered packer templates to build out various things, TeamCity build agents, base images for CentOS in our 2 main cloud providers. Then I looked at the AMIs & VHDs in our accounts – I had no idea where they came from, which template built them, from which branch, when? I started googling again, Netflix’s aminator has some hooks for some of that, but nothing concrete, and aminator is strictly AWS, we’re 90% Azure.
- The next challenge I had was proving that an image was actually good – how do I know that I haven’t just broken something or broken some security policy by tweaking something, or worse, an assumption on an installed package & that installed package changed a default, Chef’s InSpec tools allows you to do much of that, it’s also great at ensuring that you’re in compliance with security baselines, either internal or external (CIS), I’m not an InSpec expert, but I think we have a couple of Chef employees in the room who are actually paid to work on InSpec, so you should find them & poke them for more details if you’re interested.