Topics:
- How to get Dev and ITOps working together
- Looking at some tools to enable that integration
- Using Packer (https://www.packer.io/) to create images that can be used in Dev and Prod
Started of looking at the basic conflict between ITOps and Dev. In essence the risk adversity of ITOps, why its there and why its good and bad. First hand experience of this with being woken up many nights after a ‘great’ new release makes this quite pertinent.
- ITOps needs to run systems that are tested and tightly controlled – This means that when a release is coming that requires new or significantly changed components ITOps needs to be included in discussing and aware so they can ensure stability in Production
- Dev needs to adopts, trial and use new technologies to create software solutions that meet user and business requirements in a effective manner
- Performance testing needs to be conducted throughout the development iterations and this is impossible if the development environments are significantly different to production
Performance tests:
How can performance tests be conducted throughout the development of new releases, particularly if these release become more regular?
Proposed answer 1 – is a ‘Golden Image’ – A set image that is used for developing, testing and operating services. This includes Apps, Libs and OS. Docker makes this more practical with containers.
Proposed answer 2 – is to apply configuration management to all machines (not sure how practical this could be).
Practical lab:
Installed Virtualbox, Vagrant, git, ssh, Packer.
Vagrant configures VMs, Packer enabled building of ‘golden images’.
Packer template Variables:
- Builders take source image.
- Provisions install and configure software within running machine (shell, chef and puppet scripts).
- Post processors conduct tasks on images output by builders ie, compress (https://www.packer.io/docs/templates/post-processors.html). These post processors can create VMs for AWS, DigitalOcean, Hyper-V, Parallels, QEMU, VirtualBox, VMware
Lab instructions were pretty straight forward. On to lesson 3.