DEV Community: Aishwary Prakash

DevOps Interview: Replica sets vs Daemon sets

Aishwary Prakash — Sun, 10 Dec 2023 18:04:21 +0000

Replica sets and Daemon sets are controllers in Kubernetes used to manage the lifecycle of Pods. They are used to manage Pods.

Let's check the differences between them.

Replica sets ensure that a certain number of copies should be running on nodes. Daemon sets ensure exactly one copy running on all or certain nodes.
Replica sets can be scaled up or down by assigning "replicas" field in the manifest file. Daemon sets scales automatically when the node number changes.
Replica sets are used for stateless applications to maintain a certain number of instances of the application. Daemon sets are used for deploying backend services like monitoring agents, logging agents etc.
Let's see the manifest file for both.

Replica sets-

 apiVersion: apps/v1
 kind: ReplicaSet
 metadata:
   name: <any name>
 spec:
   replicas: <any number>
   selector:
     matchLabels:
       app: <any name> # any label based on your need
   template:
     metadata:
       labels:
         app: <webserver>
     spec:
       containers:
       - name: <any name>
         image: nginx:latest
         ports:
         - containerPort: 80

Daemon sets-

 apiVersion: apps/v1
 kind: DaemonSet
 metadata:
   name: <any name>
 spec:
   selector:
     matchLabels:
       app: < any name >  # any label based on your need
   template:
     metadata:
       labels:
         app: < any name>
     spec:
       containers:
       - name: <any name>
         image: fluentd:latest
         volumeMounts:
         - name: < your volume name>
           mountPath: /var/log   # any path directory on host 
       volumes:
       - name: < your volume name>
         hostPath:
           path: /var/log  # mounted volume on this path on host
node

Example of Replica sets - any web application with certain replicas etc.
Example of Daemon sets - agent deployed to collect logs from nodes.

Still confused !!

No need to worry. Let’s take daily life example for both.

Replica sets-

In a restaurant, the waiters (replicas) form a ReplicaSet. The manager, acting as the controller, ensures enough waiters are available to serve customers efficiently. If a waiter is absent, the manager replaces them with another waiter to maintain the desired number of serving staff.

Daemon sets-

In a city with a fleet of garbage trucks, each truck (pod) is assigned a specific area (node) to collect trash. The fleet manager, acting as the DaemonSet, ensures a truck is always present in every area (node) for efficient waste management.

That’s all. Pat yourself on the back. :)

Hope you enjoyed it. Don’t forget to like it.

DevOps Interview: kubectl apply vs kubectl create

Aishwary Prakash — Sun, 26 Nov 2023 03:16:36 +0000

Both kubectl create and kubectl apply are commands used to manage resources in a Kubernetes cluster.

Let’s check the differences!!

“create” is an imperative command meaning it requires you to specify all the details of the resource you want to create, including its name, labels, selectors, and other configuration options.
“apply” is a declarative command meaning it compares the desired state of a resource to its current state and makes the necessary changes.
The “create” command will fail if resources are already present. But, “apply” will update the existing resources.
“kubectl create” is not idempotent, running it multiple times will create multiple instances of the resource.
“kubectl apply” is idempotent, meaning that you can run it multiple times without affecting the resource’s state.
“kubectl create “can be used to create resources from manifest files or command-line.
“kubectl apply” can only be used to apply resources from manifest files.
Syntax:
kubectl create -f your_manifest_file_name.yaml
kubectl apply -f your_manifest_file_name.yaml

DevOps Interview: Terraform Workspace & commands

Aishwary Prakash — Thu, 23 Nov 2023 13:36:01 +0000

Terraform Workspace:

Workspace is a feature provided by Terraform to help you isolate your Terraform configurations and state files. It allows you to manage multiple sets of infrastructure resources independently, each with its own distinct configuration and state. This is useful when working with different environments such as development, staging, and production environments or projects. It helps you to isolate changes and prevent conflicts.
Each workspace will have a separate state file. If you don’t specify the workspace, Terraform automatically creates a default workspace named “default”.

so, let’s see the benefits of using Workspace.

1. Isolation — Workspaces enable you to manage separate environments, such as development, staging, and production without affecting one another environments.This way you can have different configuration files and state files.

2. Collaboration — Workspace gives team members a chance to work simultaneously on different environments without interfering with each other’s configurations.
3. Testing — Workspace helps the team to test configuration in dev or staging before applying in the prod environment. This reduces the risk of introducing errors
into pro.
4. Version control — It means if you want to keep different versions of configuration then we can use Workspace to keep track of versions.

Let’s see the commands to manage Workspace-

1. terraform workspace new : It will create new workspace.
e.g.- terraform workspace new prod

2. terraform workspace select : if you want to jump to an existing workspace.
e.g. — terraform workspace select prod

Note: we also have “ terraform workspace switch “ command for changing workspace. But there is a bit of a difference between “select” and “switch”.
terraform workspace select is used to set the currently active workspace without changing the state file, but terraform workspace switch is
set to the currently active workspace and changes the state file that is being used.
It means in the case of “terraform workspace select” , any changes you make to your configuration will still be applied to the state file for the
previously selected workspace. For “terraform workspace switch”, any changes you make to your configuration will be applied to the state file for newly selected workspace.

3. terraform workspace list: It will list all available workspaces.
e.g. — terraform workspace lists
output: dev
prod
staging

4. terraform workspace delete : It will delete particular Workspace.
e.g. — terraform workspace deletes dev

5. terraform workspace show: This command shows the name of the currently selected workspace. It will show the workspace in which currently you are.
e.g. — terraform workspace show

6. terraform workspace current: This command displays the current workspace’s name and path. It provides more detailed information about the currently
selected workspace.
e.g. — terraform workspace current

Let’s see some high-level commands…

7. terraform workspace lock: it locks the state for the currently selected workspace. This prevents other users from making changes to the state.

8. terraform workspace unlock: it unlocks the state for the currently selected workspace.

9. terraform workspace import : it imports a workspace from a source, such as a remote Terraform Cloud workspace.

10. terraform workspace export : it exports a workspace to a destination, such as a local directory.

That’s all. Pat yourself on the back. :)

Hope you enjoyed it. Don’t forget to like it.

DevOps Interview: Ansible Vaults Commands and Usuage

Aishwary Prakash — Sun, 19 Nov 2023 03:45:53 +0000

Ansible Vault is one of the most powerful features provided by Ansible. It is very useful when we are dealing with secrets, credentials, SSH keys or any other sensitive information in our playbook or role.

Let’s say you want to add credentials to your playbook for some purpose and you don’t want your password to be present in plain text. Here, you can use Ansible Vault to mask your original password. The main advantage is that this will not be visible to other users.
We will see how we can implement this. Hope, you got some idea about “Why we need Ansible Vault?”.

Encrypting file using Ansible Vault command:

We can use “ansible-vault” command to create encrypted files.

e.g.-ansible-vault create your_name_of_playbook.yml

When you run the above command, it will ask you to provide a password which will be used later to decrypt this file. This will create a new file and open it in a default text editor. Here, you can enter the secrets that you want to encrypt. After adding contents, save and close. You can see contents are encrypted.

Editing the encrypted file:

we can modify the contents of the encrypted file using “ansible-vault edit “ command. Let’s use one example.

e.g.- ansible-vault edit your_name_of_playbook.yml

When you run this command, it will ask for the vault password that you have given when encrypting this file. Enter the correct vault password, it will then decrypt the file temporarily for modification of contents. Save and exit the editor. After closing the editor, it will automatically re-encrypt the file.

Encrypting existing files:

You can also encrypt existing files using “ansible-vault encrypt” command.

e.g.- ansible-vault encrypt your_name_of_playbook.yml

It will ask you to set a new vault password which will be used while decrypting the file.

Note: you can also encrypt multiple files at once.
ansible-vault encrypt file1.yml file2.yml file3.yml

Now, if you want to decrypt the file, replace “encrypt” with “decrypt” and the rest part will be the same.
e.g.- ansible-vault decrypt your_name_of_playbook.yml

Here, it will ask for the same vault password that you have given while encrypting.

So far we discussed, how to encrypt, decrypt, and create files. Now, what if we want to change “vault password”.

are you excited to know about it? !!! :)

In Ansible, Changing the vault password is called “rekeying”. If you guessed the command will start using the word “rekey” then you are correct.

So, the command is “ansible-vault rekey”.
e.g.- ansible-vault rekey your_name_of_playbook.yml
It will ask for the current vault password. After that, you will give a new vault password as per your choice and re-confirm it. That’s all, you are all set.

Now, we have created encrypted files and you are using those files in the main playbook. But, how we will use it in our main playbook??

It is very important to provide a vault password for encrypted files while running the playbook otherwise playbook execution will fail.

Let’s see the plan:

1. Pass the vault password:
e.g.- ansible-playbook main_playbook.yml — —ask-vault-pass
It will ask for a vault password for an encrypted file used in the main playbook.

2. Pass the file having the vault password in it:
e.g.- ansible-playbook main_playbook.yml — -vault-id path_of_vault_password_file

3. Pass using vault_password_file: for this, you have to mention the path of the vault password containing the file in “ansible.cfg”
[defaults]
vault_password_file = path_of_vault_password_file

then, you can simply run “ansible-playbook mainplaybook.yml”. It will automatically find the path of the vault password file.

Note: what’s the difference in methods 2) & 3) ???

Well, it’s just a matter of interaction(method 2) and non-interaction(method 3) while executing the playbook.

I will explain “vault id significance” in the next article.

Hope you enjoyed it. Don’t forget to like it.

DevOps Interview:Absolute path and Relative path in Linux

Aishwary Prakash — Fri, 17 Nov 2023 02:48:08 +0000

Absolute path:
Absolute path is the path of any files or folders with respect to root directory (/) of the file system. It is always same.
e.g.- 1. /home/user/ec2-user/samplefile.txt → notice that it’s starting from “/” means root directory.
2. /etc/passwd
hence, you can say it’s a complete path of any file or folder.

Relative path:

Relative path is the path of any file or folder with respect to current working directory. As it’s name suggests “Relative” means there is comparison with current working directory.
e.g.- lets say current directory is “/home/user/ec2-user/documents/” (to find the path of current working directory, you can use “pwd” command)

../../ec2-user/documents/doc1.txt

hence, you can say relative path is used to denote files or folders that is present in same directory as the current working directory.

Now, you have got idea about both types of path. So, let’s check the differences on different metrics.

Absolute path always strarts from “/” root directory. But, relative path doesn’t.
Absolute path is always same irespective to current directory. But, relative path depends on current directory.
Absolute path is used to access files or folders from anywhere in system. But, relative path is used to access from current directory.
Absolut path may be lengthy when there are more subdirectories. Relative path is precise and efficient.
Absolute path is more explicit than relative path. It is easy to read absolute path and understand the flow.

Hope you enjoyed it!!