- Infrastructure as Code
- Server Provisioning
- Configuration Management
Infrastructure as Code
- Iron age -> Cloud age
- A fundamental difference between the iron age and cloud age is the move from unreliable software, which depends on the hardware to be very reliable, to software that runs reliably on unreliable hardware.
- In the cloud age, routine provisioning and change management is automated.
- In cloud world, disappearing server is a feature, not a bug
- What is Infrastructure as Code
- an approach to infrastructure automation based on software development practices
- treating infrastructure as software and data and apply software development tools (VCS) and practices (TDD, CI, CD)
- Principles of Infrastructure as Code
- Systems can be easily reproduced
- Systems are disposable (Treat your servers like cattle, not pets)
- Systems are consistent
- Processes are repeatable
- Exercise puts stress on muscles and bones, essentially damaging them, causing them to become stronger. Protecting the body by avoiding physical stress actually weakens it, making it more likely to fail in the face of extreme stress.
- Similarly, protecting an IT system by minimizing the number of changes made to it will not make it more robust. Constant changing and improving will make it more ready to handle disasters.
- Configuration tooling should run continuously, not ad hoc.
- If automation broke on some edge case, we would either change the automation to handle it, or else fix the design of the service so it was no longer an edge case.
- Dynamic Infrastructure refers to the ability to create and destroy servers programmatically;
- Issues of dynamic infrastructure
- Configuration drift
- Snowflake servers (Pets Vs Cattle) - can’t be touched, much less reproduced.
- Fragile infrastructure
- Issues of dynamic infrastructure
- Bare-metal cloud: Hardware can be automatically provisioned so that it can be used in a fully dynamic fashion. This is sometimes referred to as ‘bare-metal cloud’
- Terraform configuration files are saved as *.tf files
- Resources representinfrastructure components e.g. server, virtual machine, container, network port.
- Providers are components that let you manage a resource on a particular platform e.g. OpenStack, AWS, Google Cloud, DigitalOcean
- Provisioners provide the ability to execute commands e.g. copy a file into the VM
- Infrastructure as a Code - Tool Categories
- Configuration Management Tools
- Chef, Ansible, Puppet, Salt Stack
- Designed to install and manage software on existing servers
- Pros: coding convention, idempotent code, distribution to several servers
- Server Templating Tools
- Docker, Packer, Vagrant
- Instead of launching a bunch of servers and configuring them by running the same code on each one, the idea behind server templating tools is to create an image of a server that captures a fully self-contained “snapshot” of the operating system, the software, the files, and all other relevant details.
- Server templating is a key component of the shift to immutable infrastructure. This idea is inspired by functional programming, where variables are immutable.
- Server provisioning tools
- Terraform, AWS CloudFormation, OpenStack Heat
- Responsible for creating the servers themselves. Can also be used to create databases, caches, load balancers, queues, monitoring, subnet configurations, firewall settings, routing rules, SSL certificates, and almost every other aspect of your infrastructure
- Configuration Management Tools
terraform state show
terraform apply -var name="Fizal Terraform Instance"
- Why Configuration Management?
- Efficient Change Management
- Automated deployments
- Quick recovery from a disaster
- Well-known softwares: CFEngine, Puppet, Ansible, SaltStack, Chef
vagrant login- create login at https://app.vagrantup.com/
- Download :
vagrant box add bento/centos-7.2 --provider=virtualbox
- creates a configuration file with CPU, memory, etc.:
vagrant init bento/centos-7.2
- Uses the configuration file to create a virtual machine instance:
- Connect to the instance:
- Stop/shutdown an instance:
- Destroy vagrant instance:
vagrant destroy --force
- A recipe is a collection of resources
A cookbook is a collection of recipes
- install Chef DK
curl https://omnitruck.chef.io/install.sh | sudo bash -s -- -P chefdk -c stable -v 0.18.30
- Create recipe file
- Execute recipe file:
chef-client --local-mode hello.rb
- create a cookbook:
chef generate cookbook cookbooks/learn_chef_httpd
Run the cookbook:
sudo chef-client --local-mode --runlist 'recipe[learn_chef_httpd]'
- Sample recipe to install and start a httpd service
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24
- template, package, service: 3 types of resources built into the Chef DSL
- package: Installs a package using the appropriate platform-native installer/package manager (yum, apt, pacman, etc.).
- service: Manages the lifecycle of any daemons or services installed by the package resource.
- cookbook_file: to transfer cookbook files from
/<cookbook>/files/to the node.
- template: A variant of the cookbook_file resource that lets you create file content from variables using an Embedded Ruby (ERB) template.
- Chef client operates in 3 modes: local, client, and ?
- simulates a full Chef Server instance in memory.
- Any data that would have been saved to a server is written to the local directory (/nodes).
- The process of writing server data locally is called writeback.
- designed to support a rapid Chef recipe development by using Chef Zero, the in-memory, fast-start Chef server
- chef-client is an agent (or service/daemon) that runs locally on a machine managed by Chef.
- when chef-client is running in client mode, it assumes you have a Chef Server running on some other system on your network.
- Chef client constructs ‘node’ object in memory providing access to information about the node. It runs
ohaicommand and gathers all the node’s automatic attributes such as hostname, fqdn, ip, etc. Ohai exposes this collection of node information to Chef as a set of automatic attributes.
- To create a cookbook:
chef generate cookbook <bookname>
- To create a file in cookbook:
chef generate file <filename>
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26
- A run list contains a list of recipes to execute on the target node.
- Real-world chef runs typically involve dozens of cookbooks with possibly hundreds of recipes and associated files. There needs to be a succinct way of referring to all the files in a cookbook. That’s the purpose of a run list.
- A run list is used to specify the cookbook recipes to be evaluated on a node.
- A run list specifies recipes in the form
recipe['motd']when the Chef code is contained in the
- Run list is specified in the chef-client command or stored on a Chef server.
- For each node, Chef evaluates only recipe files that are specified on the node’s run list.
- States are stored in text files on the master and transferred to the minions on demand via the master’s File Server.
- The collection of state files make up the State Tree
- How to start the salt master/minion?
- How to check if master/minion is running?
- How to sync the changes from master to all minions?
- how to check if the changes are all synced up to all minions?
After making a change to
/etc/salt/master, restart the master daemon running,
1 2 3 4
salt '*' state.applyto instruct all minions to run state.apply.
salt-key -L- to view salt authentication keys
- Chef Cookbook
- Learning Chef - O’Reilly
- Infrastructure as Code - O’Reilly
- Terraform - Up & Running - O’Reilly