Two from our February 2017 Graduates cohort discuss their recent Graduate Project using Chef Technology to solve the problem of setting up a machine (laptop) adhering to company standards. Their aim was to introduce a working example of DevOps and learn more about that sphere. This post talks about the problem they sought to address using Chef, what DevOps is and the experience they have gained from their Graduate Project.
During a new starter’s induction day, a considerable amount of time and effort is spent on setting up a Development machine (laptop). Tasks involve downloading software and creating a folder structure which adheres to the guidelines set out by the company. This manual process is time consuming and tedious, plus it allows room for human error. The same issue occurs for a current employee who has to rebuild their machine. A third issue can be seen with employees who have forgotten the company guidelines.
Company time, in particular for new inductions, would be better spent in various other ways. Allowing the new employees to read company policy or familiarise themselves with the office building and appropriate contacts.
A key aspect of this project was to eliminate user interaction and cut down on the potential human error. To achieve this, three technologies were considered, Ansible, Puppet and Chef. We chose Chef as it is serverless, scalable and Windows compatible.
With the technology selected we looked at how best to use Chef and what it’s capabilities were. This required a lot of research – and trial and error. Understanding the problem enabled us to create three main goals: Silent Installs of required software, Folder Structure and Environment Variables, all of which were to be automated.
Our objective was for the user to simply download Chef Client, connect to the repository on InnerSource and then run a single command on the command line. The Automated process will then kick off and deliver the finished product. So what will it achieve?
- Ensures standardisation throughout the company
- Saves the company valuable time
- Speeds up Induction process
- Silent installs of software, folder structures and environment variables
Using DevOps to tackle the ‘Wall of Confusion’
In the traditional flow of software delivery, the interaction between development and support is often one of friction. Development teams are wired towards implementing change and the latest features. Support teams focus on stability of production environments through carefully constructed control measures. This divide in culture is now commonly referred to as the “wall of confusion”.
DevOps looks to break down this culture by improving the performance of the overall system, so that supporting the application is considered when it is designed. One method of doing this is to start treating your infrastructure as code so that it can be rebuilt and validated just like application code.
One area that would benefit from provisioning infrastructure would be the configuration of development environments. Setting these up can often be tedious as they rely on specific versions of software, installed in an exact order with particular environment variables and other project specific configurations – all of which can cause delays to working on a project and are prone to human error.
Automation, Automation, Automation
Chef is a powerful automation platform that uses custom Ruby DSL to provision infrastructure. A key feature of Chef is that it ensures Idempotency – only the changes that need to be applied are carried out, irrespective of the number of times it is ran. While it is intended to configure servers, the flexibility of the platform means that it can be used to set up local development environments.
Our diagram shows the architecture and workflow for the project. A developer writes Chef code on their workstation, then uploads their code to a Chef repository hosted on GitLab, and installers kept in an S3 bucket on AWS. This code can be pulled down to a developer’s machine to be configured and run in Chef Zero. This is a feature (usually used in testing code) where both a Chef Server and Chef Client are run at the same time. This approach ensures that development machines can be quickly and reliably configured for a project. This also introduces portability into development environments so that testing and support teams can recreate these environments should they need to.
Ready for the Cloud
Chef is tightly integrated with Amazon Web Services through AWS OpsWorks. This means that the Chef code used to automate physical servers or workstations can be used to configure AWS resources. This ability to standardize both physical and cloud environments means that it is possible to create a smooth workflow for both Development and Support teams.
Our Grad Project take-aways?
From experiencing work in a support team, we can see the benefits of embracing a DevOps culture and workflow. The ability to standardize environments means that Development teams are free to implement new technologies that can then be easily transferred and controlled by support teams. Having completed Phase I of ‘Ready Steady Cook’, we aim to embark on Phase II- developing an automated setup for a specific aspect in the support team.
We have both gained valuable experience in working through a project’s complete lifecycle, from inception to development to testing and production. Throughout the project we utilised Agile methodologies such as working towards fortnightly sprints and daily stand-up meetings. This project has also widened the scope of our graduate training in that we have gained certifications in Chef and are working towards certifications in other DevOps technologies.
Sopra Steria is currently recruiting for the Spring 2018 Consulting and Management Graduate Programme. If you, or someone you know, is interested in a career with us, take a look here.
Coauthored by Software Engineer Graduates, Alistair Steele and Gregg Wighton