# DevOps Zero to Hero

# Mastering Passwordless Authentication, Ansible Ad-hoc Commands, Playbooks & Roles

The journey to mastering DevOps is both challenging and rewarding, with countless opportunities to learn and grow. Recently, I reached a milestone by completing **Lecture 19** of the **DevOps Zero to Hero** course by Abhishek Veeramalla. This lecture was packed with valuable lessons on essential DevOps practices, including **passwordless authentication**, **Ansible ad-hoc commands**, **playbooks**, and **roles**.

In this post, I’ll break down the key learnings from the lecture and discuss how these concepts can be applied in real-world DevOps scenarios.

---

## 🔑 Passwordless Authentication in DevOps: A Must-Have for Efficiency

In the DevOps world, where automation and seamless communication between servers are paramount, **passwordless authentication** is indispensable. It allows you to manage multiple servers efficiently, without the need to repeatedly enter passwords, thereby saving time and enhancing security.

### Step-by-Step Guide to Setting Up Passwordless SSH Authentication

1️⃣ **Setting Up the Main and Target Servers**  
To get started, you'll need to set up a **main server** (which will be your control node) and one or more **target servers**. For my setup, I used AWS EC2 instances, which are ideal for quickly spinning up virtual servers in the cloud. The target servers will be managed remotely from the main server.

2️⃣ **Logging In and Updating the System**  
After setting up your servers, log in using SSH. It’s a good practice to update your systems right away to avoid any potential security vulnerabilities or bugs. You can do this by running the following command:

```bash
sudo apt update && sudo apt upgrade
```

This ensures that all packages and system components are up to date.

3️⃣ **Installing Ansible on the Main Server**  
Ansible is a powerful automation tool that you'll use to manage and configure your servers. To install Ansible on your main server, simply run:

```bash
sudo apt install ansible
```

This installs Ansible, which we will use later to automate various tasks.

4️⃣ **Generating SSH Keys**  
Now, it’s time to set up SSH keys for **passwordless authentication**. On the main server, generate a pair of SSH keys using the following command:

```bash
ssh-keygen
```

This command will generate a public-private key pair, which is essential for passwordless authentication. If necessary, you can also generate SSH keys for each target server.

5️⃣ **Copying the Public Key to Target Servers**  
The next step is to share the main server’s public key with each of the target servers. Start by displaying your public key:

```bash
cat ~/.ssh/id_rsa.pub
```

Then, on each target server, add the public key to the **authorized\_keys** file:

```bash
vim ~/.ssh/authorized_keys
```

This action allows the main server to access the target servers without requiring a password.

6️⃣ **Establishing the Connection**  
To test the connection, try logging into one of the target servers from the main server using its private IP address:

```bash
ssh <private_ip_of_target_server>
```

If everything is configured correctly, you should be able to log in without entering a password.

7️⃣ **Success!**  
Congratulations, you’ve set up passwordless SSH authentication! This setup is incredibly useful for managing multiple servers, as it streamlines the process of connecting to them.

---

## ⚙️ Ansible Ad-hoc Commands: Automation Made Simple

**Ansible** is a game-changing tool in the world of automation, and its **ad-hoc commands** make it even more powerful. Ad-hoc commands allow you to execute quick tasks across multiple servers without the need to write a playbook.

### A Real-World Example: Creating a File on Target Servers

Imagine you need to create a file called `devopsclass` on all your target servers. With Ansible, this task is as simple as running the following command from the main server:

```bash
ansible -i inventory all -m "shell" -a "touch devopsclass"
```

Here’s what each part of the command does:

* **\-i inventory:** Specifies the inventory file, which contains a list of target servers.
    
* **all:** Indicates that the command should run on all servers listed in the inventory.
    
* **\-m shell:** Specifies the module to use, in this case, the shell module, which allows you to execute shell commands.
    
* **\-a "touch devopsclass":** The action to be performed, which is creating a file named `devopsclass`.
    

With this single command, you can create a file on all your servers simultaneously, demonstrating how **ad-hoc commands** can simplify repetitive tasks.

---

## 📜 Ansible Playbooks: Writing Reusable Code for Server Automation

While ad-hoc commands are perfect for one-off tasks, **Ansible Playbooks** are ideal for automating more complex workflows. Playbooks allow you to define a series of tasks in a structured, repeatable manner.

### My First Ansible Playbook: Installing and Running Nginx

For this lecture, I wrote my first playbook to install and start **Nginx** on the target servers. Here’s what it looks like:

```yaml
---
- name: Install and Start Nginx
  hosts: all
  become: true
  tasks:
    - name: Install nginx
      apt:
        name: nginx
        state: present
    - name: Start nginx
      service:
        name: nginx
        state: started
```

**Explanation:**

* **hosts:** Specifies which servers to target—in this case, all servers listed in the inventory.
    
* **become: true:** Grants the necessary superuser privileges to run the tasks.
    
* **tasks:** Defines each step in the playbook. First, it installs Nginx using the apt package manager, and then it starts the Nginx service.
    

To run the playbook, use the following command:

```bash
ansible-playbook -i <inventory_file> first.yml
```

This playbook ensures that **Nginx** is installed and running on all target servers, showcasing the power and simplicity of Ansible in automating server management.

---

## 🔄 Ansible Roles: Simplifying Complex Workflows

As your infrastructure grows in complexity, managing it efficiently requires more advanced tools. **Ansible Roles** provide a way to organize your playbooks into reusable, modular components, making it easier to manage large-scale environments.

### My Experience with Ansible Roles

I experimented with creating a role for **JBoss-standalone**, but encountered some challenges, likely due to the role being outdated for newer software versions. However, I successfully used an **Ansible role** to install Docker on my target servers.

### Docker Role from Ansible Galaxy:

I found a reliable Docker role in the **Ansible Galaxy repository**, created by Jeff Geerling, a respected member of the Ansible community. You can check out the role here:  
🔗 [Ansible Role for Docker](https://github.com/Amitabh-DevOps/ansible-role-docker-example)

By using roles, you can break down complex configurations into smaller, reusable parts, making it easier to manage and scale your infrastructure.

## [**Here is pdf file which help you to understand it better :**](https://drive.google.com/file/d/1fFS_pnEByC4GeIxyreFku3btPtCgcdtL/view?usp=sharing)

---

## 🎓 Key Takeaways from This Lecture

1. **Passwordless Authentication:**
    
    * Essential for efficiently managing multiple servers by allowing seamless and secure SSH connections without needing passwords.
        
2. **Ansible Ad-hoc Commands:**
    
    * Ideal for executing quick, one-off tasks across multiple servers, saving time and effort.
        
3. **Ansible Playbooks:**
    
    * Perfect for automating a series of tasks in a structured, repeatable format, making server management more efficient.
        
4. **Ansible Roles:**
    
    * Useful for organizing complex workflows into manageable, reusable components, facilitating scalable infrastructure management.
        

---

### Conclusion

This lecture was a significant step forward in my DevOps journey. **Ansible** has proven to be an invaluable tool for automating infrastructure management, reducing the need for manual intervention, and simplifying complex configurations.

I’m eager to continue exploring **Ansible roles** and overcoming challenges like the one I faced with the **JBoss role**. As I progress, I’ll keep sharing my insights and discoveries in this exciting field of DevOps.

If you’re on a similar DevOps path or have any questions, I’d love to connect and discuss our experiences! 🚀