Ansible manages remote machines over SSH. No agents needed. You write playbooks in YAML that describe what the target state should be, and Ansible makes it happen. SSH setup Generate a key pair on the control node and copy it to your targets: ssh-keygen -t rsa ssh-copy-id username@target_host Inventory An inventory file lists your hosts and groups them: # my_inventory.ini [web] 192.168.1.2 [db] 192.168.1.3 You can also use dynamic inventory scripts that output JSON. ...
Taints and tolerations work together to control which pods land on which nodes. Taints go on nodes and repel pods. Tolerations go on pods and let them ignore specific taints. Taint effects There are three effects: NoSchedule — pods without a matching toleration won’t be scheduled on the node. Existing pods are unaffected. PreferNoSchedule — the scheduler avoids the node but will use it if there’s nowhere else. NoExecute — pods without a matching toleration are evicted from the node and won’t be rescheduled there. Applying taints # Add a taint kubectl taint nodes node1 example-key=example-value:NoSchedule # Remove a taint kubectl taint nodes node1 example-key=example-value:NoSchedule- # Multiple taints at once kubectl taint nodes node1 key1=value1:NoSchedule key2=value2:PreferNoSchedule View taints on a node: ...
I spent years watching development and operations teams sit on opposite sides of every incident. Developers pushed code over the wall. Operations inherited the fires. DevOps was supposed to fix that, but most teams just gave it a new name and kept doing the same thing. Real collaboration isn’t a poster on the breakroom wall. It’s the unglamorous daily work of making sure two groups who think differently about problems end up solving them together. ...
Running vagrant destroy sometimes fails with: VBoxManage: error: Cannot unregister the machine 'CnC_default_1643660523119_45689' while it is locked The VM is locked because a VirtualBox process is still holding onto it. Kill the headless process and try again: killall -9 VBoxHeadless && vagrant destroy killall -9 VBoxHeadless force-kills any running VirtualBox headless instances. The && runs vagrant destroy only if that succeeds.
I’ve been watching a pattern repeat itself for years, and it’s starting to grate. Someone at a conference hears about a new tool — some Kubernetes operator, or service mesh, or GitOps platform that’s supposedly going to fix everything — and they come back convinced their team needs it yesterday. Not because there’s a problem that needs solving. Because the tool exists. This isn’t about being anti-technology. I love good tools. But somewhere along the line, DevOps culture got it backwards. We’re picking solutions first and frantically searching for problems they might address, instead of looking at what’s actually broken and finding the simplest thing that fixes it. ...
Packer builds machine images. Ansible configures servers. Together, they let you bake your configuration straight into the image – no manual setup required after deployment. The Ansible provisioner in Packer runs your playbooks during the image build process. You write a normal Ansible playbook, point Packer at it, and when the image is ready, your software is already installed and configured. Note: If you specify a remote_user in your Ansible tasks, Packer will ignore it. The provisioner connects using the username from Packer’s own configuration. ...
Ultimately DevOps is an organisational transformation.
I’ve been thinking about continuous delivery a lot lately, and the thing that keeps coming back to me is how much of a pain it is when someone logs into a server and makes a change by hand. You know the type. Production is down, someone jumps in, tweaks a config file, restarts a service, and everything works again. Great. Except now that server has a configuration that exists in no repository, no documentation, and no one else’s head. Next time something breaks, you’ll spend hours chasing a difference that nobody bothered to record. ...
The idea that you could push code to production without anyone touching a server, running a script, or holding their breath still sounds a bit mad to most developers. Most teams deploy like this: someone merges code, someone else pulls it down on a staging server, runs the tests manually, fixes whatever broke, then schedules a deployment window. Someone SSHs into production, runs a script or types commands by hand, crosses their fingers, and hopes nothing catches fire. If something does go wrong, you roll back by remembering what the last working version was and praying your backups are current. ...