I will be starting 45 days of DevOps from today. The days will not be counted continuously from today. It will be counted continuously after 3 weeks when I join Sanjiv R Karn’s DevOps course.

Learning DevOps properly can take years. I am not claiming to learn DevOps in 45 days.

I am doing this to keep myself motivated while learning. I will share the entire guide in the blog post itself.

Success

Besides freshers getting an idea about DevOps, the success of the series for me will be measured as

• some projects
• a sense of confidence (very subjective thing) and fluency in DevOps

Baseline

I want to talk about my starting point. For some, what I have will be too much. Whereas for others, what I have would be too little. I am an ex-support engineer. I worked for 2 years and a few months as a support engineer before quitting my job to prepare for the Loksewa Computer Engineer and IT Officer exams.

I already have:

• Intermediate Linux skills
• intermediate web server administration skills
• beginner bash scripting skills
• exposure to Docker, Kubernetes, Vagrant, Jenkins

I feel I am weak on:

• containerization concepts
• CICD concepts

Resources

I will be using resources on demand. Mostly I will read Manning’s publications on specific topics like Kubernetes and Terraform.

But there are few resources that I have at my desk itself. One of them is Linux in Action by Manning Publications.

Another resource is the course for DevOps by Sanjiv R Karn.

I chose these resources because I have attempted many Udemy courses. Although they offer more value than what local instructors provide, they offer very little “push” factor. What I mean is the feeling of reward, the feeling of completing the assignment for the reward (potential job placement). Thus, once I am giving a try to a reputed local instructor.

Join this Discord server for discussion.

Curriculum

This is the curriculum that I will be following.

Day 1

I just started from the “Linux in Action” book by Manning.

Properties of good backup are that it should be

Reliable: use only storage media that are reliable. i.e., they should be more likely to retain their integrity for the length of time you intend to use them.

Tested: test restoring the archive as many times as possible in simulated production environments.

Distributed: Make sure that at least some of your archives are stored in a physically remote location. In case of fire or other disaster, you do not want your data to disappear along with the office.

Compliant: the backup should honor all regulatory and industry compliance requirements at all times.

Up-to-date: keep up-to-date archives.

Scripted: the backup process should be automated.

This much for today. Day 2 is not yet planned.

Day 2