DEV Community: Stanley Chinedu Ogada

A Junior DevOps Engr should be an ex-IT Operations Engineer or SysAdmin

Stanley Chinedu Ogada — Sun, 31 Mar 2024 22:42:55 +0000

My Note About DevOps

Preface

Suppose Bob👑, as a Junior DevOps Engineer, has a background as an Ex operations engineer or/and SysAdmin. In that case, he embodies a stronger DevOps Engineer profile compared to Smith😖, who holds the title of Senior DevOps Engineer but is solely an Ex Only-DevOps-Tools-User.

Key Argument: Prioritize the implementation of DevOps methodology before integrating tools (Not DevOps 👎🏽), both methodologically and technically. Learning about tools should follow a thorough understanding of systems and infrastructure

In DevOps, tools should be regarded as the final consideration. They should not take precedence in the learning journey nor be the primary focus during DevOps implementation.

💡(this is Bob👑 BTW) Learn Linux System Administration (because Cloud is Linux. lol) first before learning all 1K+ tools, Tools only help you bring the System to the Developer 🙃

Hope my Preface section is messy enough?!!

Don't be like "Senior" Smith😖 yet struggling with his all tools 👎🏽

Introduction

In recent years, the term "DevOps Engineer" has become increasingly popular in the tech industry. However, there's often confusion surrounding the exact responsibilities and skill set required for this role. Some argue that a DevOps Engineer is essentially a Cloud + Automation Engineer, while others believe there's more to it. In this blog post, we'll delve into the nuances of the DevOps Engineer role and explore why it encompasses more than just cloud computing and automation.

Table of Contents:

Understanding DevOps Engineering
The Role of Cloud Computing in DevOps
Exploring System Administration Skills
The Intersection of Software Engineering and DevOps
Debunking the Myth: DevOps Engineer vs. Cloud + Automation Engineer
Conclusion

Understanding DevOps Engineering

DevOps is a cultural and organizational approach that emphasizes collaboration, communication, and integration between software development (Dev) and IT operations (Ops) teams. DevOps engineering involves implementing practices, processes, and tools to streamline and automate the software development lifecycle.

The Role of Cloud Computing in DevOps

Cloud computing plays a crucial role in DevOps by providing a scalable and flexible infrastructure for deploying and managing applications. DevOps engineers leverage cloud services and platforms to build and maintain infrastructure as code, enabling rapid provisioning, scalability, and automation.

Exploring System Administration Skills

SysAdmin skills are essential for DevOps engineers, as they involve managing and maintaining the infrastructure and tooling that support software development and deployment. This includes tasks such as server configuration, networking, security, automation, and monitoring.

The Intersection of Software Engineering and DevOps

While DevOps engineers may not primarily focus on writing application code, they often have some knowledge of software development principles and practices. They collaborate with developers to define infrastructure requirements, troubleshoot deployment issues, and optimize application performance.

Debunking the Myth: DevOps Engineer vs. Cloud + Automation Engineer

While it's true that DevOps engineers require skills in cloud computing and automation, their role extends beyond that. DevOps engineering involves a combination of cloud computing, system administration, software engineering, collaboration, and automation to enable efficient software delivery. However, it is my firm belief that a DevOps Engineer should have a very strong background and skills in IT Ops/Cloud Computing and SysAdmin. Essentially, combining expertise from both former IT Ops and SysAdmin roles creates an even stronger DevOps Engineer at the bare minimum.

Conclusion

The role of a DevOps Engineer is multifaceted, encompassing skills in cloud computing, system administration, software engineering, collaboration, and automation (Essentially Jack of all trades). While cloud computing and automation are important aspects of DevOps, they are just one part of the broader skill set required for success in this role. Understanding the full scope of DevOps engineering, including strong backgrounds in IT Ops and SysAdmin, is essential for organizations looking to adopt DevOps practices effectively.

Lite Neovim Distro: A Blazing Fast, Lightweight Neovim Setup

Stanley Chinedu Ogada — Sat, 24 Feb 2024 00:44:13 +0000

Introduction
Motivation
Features
Usage
Conclusions
Social Links

Introduction

Welcome to Lite Neovim Distro, a project tailored for those eager to dive into Neovim without any prior configuration knowledge, including my future self! 😄 This minimalist Neovim distribution offers a lightning-fast and lightweight setup right out of the gate.

What sets this project apart is its comprehensive guide. Whether you're interested in configuring Neovim yourself or simply want to jump right in, our guide covers all the prerequisites and installation steps to get you up and running with my customized Neovim configuration. Don't hesitate to explore it!

Motivation

As a Vim aficionado, I've always admired its efficiency. While it's perfect for basic tasks, I often resorted to VSCode for more complex projects. Seeking to streamline my workflow, I experimented with various setups, ultimately embracing Neovim with Lua scripting for its speed and flexibility.

Existing distributions like NVChad were bogged down with plugins, slowing performance. Hence, I crafted a custom configuration focused solely on essential plugins. With Packer and Lua, I optimized my setup for efficiency and speed.

Managing this setup across different systems posed challenges. To simplify, I meticulously documented prerequisites and streamlined installation to a single step. Now, setting up my Neovim environment is quick and consistent across systems.

Picture yourself on a server needing quick edits. With Lite Neovim Distro, you can swiftly establish a lightweight Neovim environment, boosting efficiency and productivity.

Features

Key Notes:

The <leader> is the space key.

This distro comes with only the NodeJs Debugger. I'm not a Debugger guy :)

I have configured only for the following; Find Tweak the config from the Adapter's section

Javascript/Typescript: Tested

Testing with Jest (Assumes you have Jest installed on your local project): Tested

React Vite: Tested

React NextJs: Not-Tested

So if you need a debugger for any other programming language you will need to configure it yourself

PACKER:
- An easy-to-use plugin manager. (Optional Read more about this plugin)
TELESCOPE:
- Fuzzy finding (<leader>ff), live grep (<leader>fg), etc. (Optional Read more about this plugin)
GITHUB-THEME:
- A beautiful GitHub theme pack (:colorscheme github_dark). (Optional Read more about this plugin)
NVIM-TREE:
- A modern File tree (<leader>n), etc. (Optional Read more about this plugin)
WEB-DEVICONS:
- Displays icons. (Optional Read more about this plugin)
LUALINE:
- A beautiful status line. (Optional Read more about this plugin)
TREESITTER:
- Syntax highlighting, etc. (Optional Read more about this plugin)
GITSIGNS:
- Signs for added, removed, and changed lines, etc. (Optional Read more about this plugin)
BARBAR:
- A beautiful tabs manager (<leader>bq -> quit the current tab). (Optional Read more about this plugin)
MININTRO:
- A beautiful "NEOVIM" intro when you type just nvim from the OS's terminal. (Optional Read more about this plugin)
TELESCOPE-UNDO:
- A telescope extension for undo history (<leader>fu). (Optional Read more about this plugin)
OIL:
- A beautiful and fast file explorer (- -> Opens current/previous directory). (Optional Read more about this plugin)
NVTERM:
- A beautiful terminal emulator (<leader>tv -> Toggle vertical terminal). (Optional Read more about this plugin)
GITHUB-COPILOT:
- AI-powered code completion (<TAB> -> autocomplete the suggestion). (Optional Read more about this plugin)
WHICH-KEY:
- A keybindings helper. (Optional Read more about this plugin)
ZEN-MODE:
- A distraction-free writing (focus) mode. (Optional Read more about this plugin)
TELESCOPE-TODO-COMMENTS:
- A telescope extension to manage all todo comments (<leader>fc -> list all todo comments). (Optional Read more about this plugin)
AUTO-SESSION:
- Let Neovim remember your opened files (<leader>fs -> switch to previously saved sessions). (Optional Read more about this plugin)
COMMENT:
- Toggle comments with ease (gcc). (Optional Read more about this plugin)
SURROUND:
- Surround text with ease (ysiw} -> surrounds word with {}). (Optional Read more about this plugin)
VISUAL-MULTI:
- Work with Multiple cursors (<C-n>). (Optional Read more about this plugin)
COC:
- A marketplace (:CocInstall marketplace) packed with extensions (<leader>m), like LSPs (:CocInstall coc-tsserver), linters (:CocInstall coc-eslint), etc. (Optional Read more about this plugin)
DAP:
- A debugger for Neovim (<leader>dc -> continue, <leader>db -> toggle breakpoint). (Optional Read more about this plugin)
NVIM-DAP-VSCODE-JS:
- A NodeJS Debug Adapter. (Optional Read more about this plugin)

Usage

To use Lite Neovim Distro, follow these steps:

Backup or Remove your existing Neovim config (~/.config/nvim). If you don't have any existing Neovim configuration, you can skip this step.

Install the config:

 git clone https://github.com/stanleyogada/lite-neovim-distro.git ~/.config/nvim && nvim

Note: If you get an error, just Hit the ENTER KEY on your keyboard twice and Packer will fix the errors and set everything up for you.
If you're still getting any errors, you might be missing 1 or more requirements on your system, definitely check out the docs for more info

You're all set 🚀
```
 nvim
```

Conclusions

Lite Neovim Distro provides a streamlined Neovim setup, prioritizing speed and efficiency. With its minimalist approach and essential plugins, you can enjoy a powerful editing experience without the bloat. Give it a try and elevate your text editing workflow!

Social Links

GitHub Profile
LinkedIn Profile
Project Repo

Documenting Your Tech Journey: The Key to Success

Stanley Chinedu Ogada — Thu, 08 Feb 2024 15:08:40 +0000

Table of Contents:

Introduction
Why Documentation Matters
What Do We Mean by Documenting Your Work?
The Power of Sharing
Embracing Every Opportunity
The Role of AI with Prompt Engineering
Conclusion

Introduction:

In the fast-paced world of technology, success isn't just about the code you write or the systems you build—it's also about the story you tell. Each line of code, every project you undertake, is a chapter in your tech journey. But how do you ensure your story stands out in a sea of aspiring developers and engineers? The answer lies in one word: documentation.

Why Documentation Matters:

Documentation isn't just a mundane task—it's your strongest alibi, your evidence that you've journeyed through the vast landscape of technology and gained valuable insights along the way. It's about more than just showcasing your skills; it's about demonstrating your thought process, problem-solving abilities, and commitment to continuous improvement.

Documenting how you solved a problem or why that problem could potentially save your future self assuming you encounter it again (More of like a quick reference 🙂).

What Do I Mean by Documenting Your Work?

Documenting your work means sharing your learnings, triumphs, and challenges. It's about capturing the essence of your experiences and sharing them with the world. Whether it's through writing a blog post, creating engaging content for YouTube or TikTok, or contributing to open-source projects on GitHub, documenting your journey is key.

The Power of Sharing:

When you document your work, you're not just creating a portfolio—you're building a community. By sharing your experiences, insights, and discoveries, you're contributing to the collective knowledge of the tech community. You never know who might benefit from your insights or find inspiration in your projects.

Embracing Every Opportunity:

Remember, it's not just about the result; it's about the journey. Embrace every opportunity to learn, grow, and share your knowledge with others. Each project, no matter how small, is an opportunity to showcase your skills and make a difference in the tech world.

The Role of AI with Prompt Engineering:

In the modern digital landscape, leveraging artificial intelligence (AI) can significantly enhance your documentation efforts. Embrace the opportunities afforded by AI technology to streamline your workflow and ensure accuracy in your work. Remember to tap into the expertise of peers, colleagues, mentors, and AI systems to cross-check your writing and validate its content (A useful one could be Grammarly). Cultivating proficiency in AI prompt engineering is becoming essential in today's professional sphere, so take advantage of the resources and training available to hone this skill. By integrating AI into your documentation process, you can optimize efficiency and maintain high-quality standards.

Conclusion:

In conclusion, documenting your tech journey is more than just a task—it's a mindset. It's about embracing the process, celebrating your successes, and learning from your failures. So, don't hold back—document your work, share your story, and let your passion for technology shine through. With determination, resilience, and a touch of creativity, the possibilities are endless.

Wishing you all the luck in your tech endeavors! Keep pushing boundaries, breaking barriers, and reaching for the stars. Your journey is just beginning.

Also, connect with me on LinkedIn

Happy hacking!

Bridging 2 VEth Devices within Namespaces

Stanley Chinedu Ogada — Thu, 08 Feb 2024 13:20:04 +0000

Table of Contents:

Introduction
Understanding Network Bridging
Understanding Network Namespaces
Connecting Network Namespaces with a Bridge
PRACTICAL GUIDE
Real-world scenarios for creating multiple namespaces
Conclusion

Introduction:

In the world of Linux networking, understanding concepts like network bridging and network namespaces can open up a realm of possibilities for network configuration, isolation, and testing. In this blog post, we'll delve into these concepts, exploring their use cases and providing a step-by-step guide to implementing them on your Linux system.

Understanding Network Bridging:

Network bridging is a technique used to connect multiple network interfaces, allowing them to communicate with each other as if they were part of the same network segment. This is achieved by creating a virtual bridge interface that acts as a hub for the connected interfaces.

Understanding Network Namespaces:

Network namespaces provide a way to create isolated network environments within a Linux system. Each namespace has its network stack, including interfaces, routing tables, and firewall rules, allowing for separate network configurations.

Connecting Network Namespaces with a Bridge:

While network namespaces provide isolation, there may be scenarios where communication between namespaces is desired. This can be achieved by connecting the namespaces using a bridge, allowing for controlled communication between them.

Practical Guide:

Create a bridge:

ip link add br0 type bridge

Create the veth network interfaces and their peers:

ip link add vth1 type veth peer vth_1
ip link add vth2 type veth peer vth_2

These commands create two pairs of virtual Ethernet (veth) interfaces (vth1 and vth2) along with their peers (vth_1 and vth_2). Each veth pair acts as a virtual cable, where data sent through one end of the pair emerges at the other end.

Create 2 network namespaces:

ip netns add ns1
ip netns add ns2

Move the veth peers to each namespace:

ip link set dev vth_1 netns ns1
ip link set dev vth_2 netns ns2

These commands move the veth peer interfaces (vth_1 and vth_2) into their respective network namespaces (ns1 and ns2), effectively associating them with the namespaces.

Assign an IP address to the veth network interface in each network namespace:

ip netns exec ns1 ip address add 192.168.10.1/24 dev vth_1
ip netns exec ns1 ip link set dev vth_1 up

ip netns exec ns2 ip address add 192.168.10.2/24 dev vth_2
ip netns exec ns2 ip link set dev vth_2 up

These commands assign IP addresses to the veth interfaces (vth_1 and vth_2) inside their respective namespaces (ns1 and ns2). Additionally, they bring up the interfaces (vth_1 and vth_2) within their namespaces.

Add the veth network interfaces to the bridge:

ip link set dev vth1 master br0
ip link set dev vth2 master br0

These commands add the veth interfaces (vth1 and vth2) to the bridge (br0). By adding the interfaces to the bridge, traffic can flow between the namespaces through the bridge.

Bring up the bridge and the veth network interfaces:

ip link set dev br0 up
ip link set dev vth1 up
ip link set dev vth2 up

These commands bring up the bridge (br0) and the veth interfaces (vth1 and vth2), enabling network connectivity.

Test connectivity between namespaces using ping:

ping 192.168.10.1;
ping 192.168.10.2;

These commands attempt to ping the IP address 192.168.10.1 and 192.168.10.2. Since the bridge is not directly connected to the physical network, the ping fails.

ip netns exec ns1 ping 192.168.10.2 -c2

This command uses the ip netns exec command to execute the ping from within the ns1 namespace. As a result, the ping is successful with 0% packet loss.

ip netns exec ns2 ping 192.168.10.1 -c2

Similarly, this command executes the ping from within the ns2 namespace, resulting in a successful ping with 0% packet loss.

However, ns1 can only ping ns2 (with its IP address of course) but can't ping itself (ns1 can't ping ns1), and the same situation for the ns2 namespace as well. Well, the reason is the lo devices in a newly created namespace are down by default.

In other words (Optionally), If you wish for the ns1 and ns1 to ping itself, then bring up the lo devices

ip netns exec ns1 ip link set dev lo up
ip netns exec ns2 ip link set dev lo up

The ns1 can now ping both ns2 (192.168.10.2) and itself (192.168.10.1) and the same is true for the ns2 namespace.

ip netns exec ns1 ping 192.168.10.1 -c2
ip netns exec ns1 ping 192.168.10.2 -c2

Real-world scenarios for creating multiple namespaces:

Service or application isolation:
In a cloud environment, different services or applications may require isolated network environments for testing or development. By creating multiple namespaces on a single machine and connecting them using a bridge, developers can simulate isolated network environments for each service or application without the need for additional physical hardware.
Security testing:
Security researchers or penetration testers often require isolated environments to conduct security testing or analysis. By creating multiple namespaces on a single machine and connecting them using a bridge, they can simulate complex network topologies and test various security scenarios without impacting production systems. This setup allows for controlled experimentation and analysis of network-based vulnerabilities and attack vectors.

NOTE:

It's essential to note that the use of a bridge in this scenario doesn't completely negate the isolation provided by the namespaces. The namespaces still maintain separate network configurations, IP addresses, and routing tables, ensuring that network traffic remains isolated within each namespace by default.

The point of connecting the namespaces with a bridge is to enable controlled communication between them when necessary, such as for testing network communication between different services or applications running in separate namespaces. It allows for flexibility in network configuration while still providing isolation where needed.

Conclusion:

Network bridging and network namespaces are powerful tools in the Linux networking toolbox, offering flexibility, isolation, and control over network configurations. By understanding these concepts and how to implement them, you can tailor your Linux network environment to suit your specific needs, whether it's for testing, development, or production use. With the step-by-step guide provided in this blog post, you can start exploring the possibilities of Linux networking bridging and namespaces in your projects.

Also, connect with me on LinkedIn

Happy hacking!

Automated Backups Made Easy: & Lessons Learned From This Project

Stanley Chinedu Ogada — Thu, 01 Feb 2024 13:09:16 +0000

Table of Contents:

Introduction
Project Overview
Discoveries and Resolutions
- Use Full Paths in Crontabs
- Specify Full Paths for Rsync and SSH Key
Conclusion

Introduction:

In the ever-evolving world of technology, ensuring the safety of our data is paramount. Recently, I completed a project that automates backup tasks, aiming to simplify the process and enhance data security. While the project proved successful, I encountered a stumbling block that led me on a troubleshooting journey. In this blog post, I'll share the project overview and the valuable lessons learned from resolving a crucial issue.

Project Overview:

The project (GitHub link: Auto-Backup Project) automates the addition of backup tasks to the crontab for daily, weekly, and monthly backups. All compressions (.tar.gz) are stored in a designated backup directory, and SSH key authentication is required for remote hosts. The script intelligently manages backup files, retaining only the most recent ones to optimize storage usage.

Discoveries and Resolutions:

While developing the project, a significant challenge surfaced when incorporating the rsync command into the script for scheduled execution via crontab. Here are the two major discoveries that solved the issue:

Use Full Paths in Crontabs:

Crontab entries should include the full path to scripts. Correct example:
```
 * * * * * /usr/local/bin/backup.sh
```

Specify Full Paths for Rsync and SSH Key

In the script, provide the full path to the rsync program and explicitly specify the SSH key for the remote system.
```
 /usr/bin/rsync -a -e "ssh -i /home/user/.ssh/vps-1-private-key" /home/user/backups user@vps-1.com
```
To troubleshoot, add verbose logging with the -vv option to the rsync in the script and redirect the crontab output to a file for monitoring.
```
 * * * * * /usr/local/bin/backup.sh >> /home/user/.backup.cron.log 
```

Conclusion:

Developing the Auto-Backup Project was a rewarding experience, and overcoming the challenge highlighted the importance of attention to detail. By sharing these discoveries, I hope to assist fellow developers facing similar issues. Remember, the devil is in the details, and providing full paths can make all the difference in the world of scheduled tasks. Explore the GitHub repository for more details and project documentation.

Check out a related problem posted on StackOverFlow

Also, connect with me on LinkedIn

Happy hacking!

Get a practice Ansible Lab in 1 step -- Powered by Docker

Stanley Chinedu Ogada — Fri, 19 Jan 2024 09:47:27 +0000

Why This Project?
Project Goals
Documentation
- Docker Ansible Lab Configuration
- Prerequisites
- Usage Instructions
  - Control-Host Usage
  - Server Usage (Example for Server-1)
Conclusion and Useful Links

Why This Project?

The motivation behind this Docker Ansible Lab project is to eliminate the headaches associated with creating a lab environment for Ansible practice. The traditional setup demands a robust machine capable of running at least three VMs, with various configurations such as network establishment and SSH communication. This project aims to simplify the process by allowing users to set up a scalable lab environment within Docker, with minimal configuration requirements.

Project Goals

The primary goal of the Docker Ansible Lab project is to enable users to effortlessly set up a lab environment within a Docker container. Unlike traditional setups, this project offers scalability, allowing users to create more than three machines with ease. The emphasis here is on minimizing the setup steps and allowing users to dive straight into Ansible without worrying about the intricacies of lab configuration.

Documentation

Docker Ansible Lab Configuration

Note: This configuration will create a total of five nodes, including three Ubuntu and two Oracle Linux machines. Refer to the docker-compose.yaml file for details.

Node Credentials:

Username: zero
Password: ][poiuy

Prerequisites

Before getting started, ensure the following prerequisites are met:

Docker installed on your machine
Docker Compose installed
Docker daemon started
For Ubuntu, consider adding your user to the docker group
Optionally, install the provided version (refer to the screenshot below) of higher

Usage Instructions

Clone the repository and navigate to it.
Run docker-compose up -d.
View the logs using docker-compose logs -f.
Wait for approximately 1-5 minutes until you see a message indicating "SUCCESS! ... Happy hacking!"
Your Ansible lab is now ready!

Control-Host Usage

Open a new terminal for each control host.
Run docker container exec -it control-host bash.
Stay as the root user.
In the container, navigate to cd ~/ansible-project as this is your base Ansible directory.
Your lab is ready! You can now control and configure all servers. Test server connections with ansible all -m ping.

Server Usage (Example for Server-1)

Open a new terminal for each server.
Run docker container exec -it server-1 bash.
Switch to the zero user by running su - zero and use the password \][poiuy.

Conclusion and Useful Links

Simplify your Ansible learning journey with this Docker Ansible Lab setup, and enjoy a seamless and scalable environment for honing your skills. For further engagement, you can connect with me on LinkedIn. Additionally, explore the project on GitHub for more details and updates (Please star this project 🙏 ). Happy hacking!