<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>Automation on ayyzenn</title><link>https://ayyzenn.github.io/tags/automation/</link><description>Recent content in Automation on ayyzenn</description><generator>Hugo -- 0.163.3</generator><language>en-us</language><lastBuildDate>Mon, 09 Feb 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://ayyzenn.github.io/tags/automation/index.xml" rel="self" type="application/rss+xml"/><item><title>Jenkins on Arch Linux: How I Set It Up on i3</title><link>https://ayyzenn.github.io/posts/jenkins-on-arch-linux/</link><pubDate>Mon, 09 Feb 2026 00:00:00 +0000</pubDate><guid>https://ayyzenn.github.io/posts/jenkins-on-arch-linux/</guid><description>&lt;h2 id="why-i-wrote-this"&gt;Why I Wrote This&lt;/h2&gt;
&lt;p&gt;I run Arch Linux with i3 and wanted Jenkins locally for CI/CD experiments. This covers Java 21, the Jenkins install, a test job, and a GitHub pipeline — exactly what I ran on my machine.&lt;/p&gt;
&lt;hr&gt;
&lt;h2 id="1-what-is-jenkins-simple-explanation"&gt;1. What is Jenkins? (Simple Explanation)&lt;/h2&gt;
&lt;p&gt;&lt;strong&gt;Jenkins is an automation server.&lt;/strong&gt;&lt;/p&gt;
&lt;p&gt;You can tell Jenkins to:&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;Get your code (for example from GitHub)&lt;/li&gt;
&lt;li&gt;Run commands (build, test, scripts)&lt;/li&gt;
&lt;li&gt;Show you if things passed or failed&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;Instead of you running commands manually every time, Jenkins does it &lt;strong&gt;automatically&lt;/strong&gt;.&lt;/p&gt;</description></item><item><title>Ansible: Docker and Kubernetes Node Setup</title><link>https://ayyzenn.github.io/posts/ansible_adv/</link><pubDate>Sat, 17 Jan 2026 00:00:00 +0000</pubDate><guid>https://ayyzenn.github.io/posts/ansible_adv/</guid><description>&lt;h2 id="why-this-post-exists"&gt;Why This Post Exists&lt;/h2&gt;
&lt;p&gt;After writing my &lt;strong&gt;first real Ansible playbook&lt;/strong&gt;, I realized something:&lt;/p&gt;
&lt;blockquote&gt;
&lt;p&gt;Installing software manually once is easy.
Installing it &lt;strong&gt;correctly, repeatedly, and safely&lt;/strong&gt; is not.&lt;/p&gt;
&lt;/blockquote&gt;
&lt;p&gt;So I decided to automate something &lt;strong&gt;real&lt;/strong&gt; and &lt;strong&gt;useful&lt;/strong&gt;:&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;Install &lt;strong&gt;Docker Engine (official way)&lt;/strong&gt;&lt;/li&gt;
&lt;li&gt;Prepare an Ubuntu server to become a &lt;strong&gt;Kubernetes node&lt;/strong&gt;&lt;/li&gt;
&lt;li&gt;Do everything using &lt;strong&gt;Ansible&lt;/strong&gt;&lt;/li&gt;
&lt;li&gt;No SSH-ing into the server again and again&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;This post documents that journey.&lt;/p&gt;
&lt;hr&gt;
&lt;h2 id="real-setup-same-as-before"&gt;Real Setup (Same as Before)&lt;/h2&gt;
&lt;p&gt;Nothing fancy. Just real machines.&lt;/p&gt;</description></item><item><title>Ansible for Beginners: My First Real Automation</title><link>https://ayyzenn.github.io/posts/ansible/</link><pubDate>Thu, 15 Jan 2026 00:00:00 +0000</pubDate><guid>https://ayyzenn.github.io/posts/ansible/</guid><description>&lt;h2 id="what-is-ansible-in-simple-words"&gt;What is Ansible? (In Simple Words)&lt;/h2&gt;
&lt;p&gt;Think of &lt;strong&gt;Ansible as a remote control for your servers&lt;/strong&gt;.&lt;/p&gt;
&lt;p&gt;Instead of:&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;SSH into server&lt;/li&gt;
&lt;li&gt;Run commands manually&lt;/li&gt;
&lt;li&gt;Forget what you changed&lt;/li&gt;
&lt;li&gt;Repeat the same steps again and again&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;You tell Ansible:&lt;/p&gt;
&lt;blockquote&gt;
&lt;p&gt;“Hey, I want this server to look &lt;em&gt;like this&lt;/em&gt;.”&lt;/p&gt;
&lt;/blockquote&gt;
&lt;p&gt;And Ansible makes it happen — &lt;strong&gt;again and again&lt;/strong&gt;, without breaking things.&lt;/p&gt;
&lt;p&gt;The best part?&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;No agent needed&lt;/li&gt;
&lt;li&gt;Just SSH&lt;/li&gt;
&lt;li&gt;Simple YAML files&lt;/li&gt;
&lt;li&gt;Very human-readable&lt;/li&gt;
&lt;/ul&gt;
&lt;hr&gt;
&lt;h2 id="my-setup-real-world"&gt;My Setup (Real World)&lt;/h2&gt;
&lt;p&gt;This is exactly what I used:&lt;/p&gt;</description></item><item><title>Terraform: How I Stopped Clicking Around in AWS</title><link>https://ayyzenn.github.io/posts/terraform/</link><pubDate>Sun, 14 Dec 2025 00:00:00 +0000</pubDate><guid>https://ayyzenn.github.io/posts/terraform/</guid><description>&lt;h2 id="what-terraform-is-for-me"&gt;What Terraform Is (For Me)&lt;/h2&gt;
&lt;p&gt;Terraform is how I describe cloud stuff in code instead of clicking through the AWS console. I write what I want in &lt;code&gt;.tf&lt;/code&gt; files, run &lt;code&gt;terraform apply&lt;/code&gt;, and it gets created. Same result every time.&lt;/p&gt;
&lt;h2 id="why-use-terraform"&gt;Why Use Terraform?&lt;/h2&gt;
&lt;ul&gt;
&lt;li&gt;&lt;strong&gt;No More Manual Clicking&lt;/strong&gt;: Automate infrastructure setup instead of clicking through AWS&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;Easy Updates&lt;/strong&gt;: Change your code and run &lt;code&gt;terraform apply&lt;/code&gt; to update everything&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;Backup Your Infrastructure&lt;/strong&gt;: Keep your setup in version control (like Git)&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;Reuse Everywhere&lt;/strong&gt;: Run the same setup in dev, staging, and production without changes&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;Cost Preview&lt;/strong&gt;: See what resources cost before you create them&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;Work with Multiple Clouds&lt;/strong&gt;: Manage AWS, Azure, and Google Cloud from one tool&lt;/li&gt;
&lt;/ul&gt;
&lt;h2 id="basic-concepts-made-simple"&gt;Basic Concepts (Made Simple)&lt;/h2&gt;
&lt;h3 id="providers"&gt;Providers&lt;/h3&gt;
&lt;p&gt;A &lt;strong&gt;provider&lt;/strong&gt; tells Terraform which cloud service to use. Think of it as picking AWS, Google Cloud, or Azure before you start building.&lt;/p&gt;</description></item><item><title>Chef Server Setup: What I Did on Ubuntu</title><link>https://ayyzenn.github.io/posts/chef/</link><pubDate>Tue, 02 Aug 2022 00:00:00 +0000</pubDate><guid>https://ayyzenn.github.io/posts/chef/</guid><description>&lt;h2 id="why-i-looked-into-chef"&gt;Why I Looked Into Chef&lt;/h2&gt;
&lt;p&gt;Managing servers one by one doesn&amp;rsquo;t scale. I set up &lt;strong&gt;Chef&lt;/strong&gt; to store server configs as code — a Chef server, a workstation where I write recipes, and a node that pulls its config automatically.&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;Note:&lt;/strong&gt; I did this on &lt;strong&gt;Ubuntu 18.04&lt;/strong&gt; using &lt;code&gt;.deb&lt;/code&gt; packages and &lt;code&gt;apt&lt;/code&gt;.&lt;/p&gt;
&lt;h2 id="chef-server"&gt;Chef Server&lt;/h2&gt;
&lt;p&gt;The Chef server acts as the central hub for all workstations and nodes under Chef management. Configuration changes made on workstations are pushed to the Chef server, where they are pulled by nodes using &lt;code&gt;chef-client&lt;/code&gt; to apply the configurations.&lt;/p&gt;</description></item></channel></rss>