Becoming Successful in DevOps: A Beginners Guide

Where to start

As a platform engineer, you will be tasked with ensuring that software projects run smoothly and efficiently. This includes managing all of the various components needed to develop and launch an app or system.

This may include choosing your development platform, setting up servers for hosting, finding vendors for integrations, and more. Beyond just technology, there are also time-management strategies to manage your day.

As you can imagine, being a part of this team comes with its own set of challenges and responsibilities. Being a senior member of the team takes some work — but it is totally worth it!

Being a senior developer means that you know what’s going on technologically, and you’re able to teach others that knowledge. You’ll have the opportunity to make an impact by helping other engineers get things done effectively.

It’s also important to remember that not everyone has a career in tech like you do, so don’t feel like you need to take over every task.

Plan your career

7 things to know as a devops engineer

As mentioned earlier, being a successful platform engineer is more than just knowing how to work in different environments having separate and distinctly different conversations with various people about what tools you use for each environment, and how to manage your time effectively between projects and departments. It also means planning your career ahead of time.

Most experienced devs will tell you that it’s impossible to become a senior developer without first becoming a team lead or manager. This makes sense, because you need to establish relationships within the department and organization that depend on you for leadership, guidance, and resources.

And since most tech companies are moving towards agile project management systems like Scrum, you need to be able to facilitate those meetings, talk about logistics, and make sure everyone has everything they need to complete their assignments on schedule.

All of these things require someone who leads by example, sets appropriate priorities, and keeps people motivated so that they feel comfortable coming to you for help when needed. You can’t expect anyone lower up the chain-of-command to do this if they don’t see you putting in the effort into developing your leadership skills.

It’s totally normal to want to move up the ladder, but making changes to your position requires proving that you’re capable of doing so while still keeping quality control over your tasks and setting realistic deadlines.

Create a good work-life balance

7 things to know as a devops engineer

Being a platform engineer means having close relationships with other people in your organization that depend on you for success, so make sure you are not overworking yourself.

It is important to enjoy what you do for a living, and staying motivated requires finding time to unwind and relax. You can’t expect to be passionate about your job if you don’t take care of yourself outside of work.

You need to recognize that it takes a lot out of you, both physically and mentally, and give yourself breaks to keep up momentum. Take frequent vacations, organize social events outside of work, and try to limit how many hours you spend working every day.

In addition to taking care of yourself, use the same energy you put into your career on your personal life to promote healthy relationships and friendships.

Having friends who treat you well will help you feel more balanced and confident in your position, and they will help you stay happier at home. Try to meet someone new once a week, if possible, to maintain strong ties with family members and colleagues.

Be a creative thinker

7 things to know as a devops engineer

As a platform engineer, you will be tasked with many different projects and responsibilities. This can make it hard to know what your next job is! As such, being able to think outside of the box and brainstorm new ideas and solutions to current issues is important.

You will have to use your creativity to figure out how to best solve these problems.

A great way to hone this skill is by taking part in various tech events or masterclasses. You may even get chance to present your own project or idea!

By attending events like these, not only do they give you knowledge about the field, but also lots of opportunities to improve yourself professionally.

Stay up-to-date with technology

7 things to know as a devops engineer

As a platform engineer, you will be tasked with keeping up with new technologies. This is not only important for your career, but also to satisfy users’ demands for quality services they can rely on.

As more companies implement automation via software or robotics, there are always new tools being used for this process. You will need to know what these tools are and how to use them.

You will also have to stay up-to-date with the ever-evolving practices in both development and operations. For example, when developers adopt newer agile methodologies like scrum, you must understand why that approach is better than the traditional waterfall model.

Likewise, understanding lean startup methodology means knowing why it works and if it applies to your organization. These concepts help bring down the overhead of launching an app by reducing the number of steps needed to get things going.

By staying informed about such developments, you will make sure apps launch as quickly as possible while still meeting standards.

Be a good leader

7 things to know as a devops engineer

As a platform engineer, you will be in charge of many different departments within your organization. You can expect that not every department in your own company or others you work with have strong leadership qualities.

If this is something that worries you, don’t worry! It’s totally normal.

It takes time to develop leadership skills, but you are never too young or old to learn them.

You can always look to those around you for examples of how to lead and learn from their mistakes. There are several books and courses available online and through educational institutions that focus on developing leadership abilities.

There are also mentorship programs where experienced leaders share knowledge and resources with younger people. By being part of these groups, you could gain some valuable lessons yourself.

Be a good team member

7 things to know as a devops engineer

As a platform engineer, your success will depend on how well you collaborate with others. You can’t have successful collaborations if one party is constantly trying to get their way or take over the process.

This isn’t helpful for anyone involved in the project, and it won’t set well with leadership either. Make every effort to work with people around you using sound reasoning and evidence, and keep discussions focused on topics that are productive and positive.

Avoid gossip unless you want to deal with a lot of resentment later, and be willing to go beyond what is practical or appropriate to help someone feel better about themselves or the situation.

Creating a pipeline in Gitlab

Creating a pipeline in Gitlab is a great way to deploy applications to various environments. It allows you to automate the process of building, testing, and deploying your application. With Gitlab, you can define a pipeline that consists of a series of stages, which can include tasks such as building the application, running tests, and deploying the application. By leveraging the power of a pipeline, you can ensure that your application is deployed quickly, efficiently, and with minimal hassle. This guide will walk you through the steps to create a pipeline in Gitlab, with code examples.

Step 1: Creating a New Project

To start a new pipeline, you will first need to create a new project in Gitlab. To do this, you can go to Projects > New Project and fill out the form.

Step 2: Creating the Pipeline

Once the project is created, you can go to CI/CD > Pipelines and create a new pipeline. You will be able to define the stages and tasks for the pipeline, and even add code snippets to configure the pipeline. Here is an example of a simple pipeline:

stages:
  - build
  - test
  - deploy

build:
  stage: build
  script:
    - npm install
    - npm build

test:
  stage: test
  script:
    - npm test

deploy:
  stage: deploy
  script:
    - npm deploy

Step 3: Running the Pipeline

Once you have created the pipeline, you can run it by going to CI/CD > Pipelines and clicking the “Run Pipeline” button. This will execute the pipeline, and you can check the progress of the pipeline in the pipeline view.

Step 4: Troubleshooting

If you encounter any issues while running the pipeline, you can click on the pipeline to open up the pipeline view. Here, you will be able to view the log output of each stage, and debug any issues that may be occurring.

Conclusion

Creating a pipeline in Gitlab is a great way to easily deploy applications to various environments. By leveraging the power of a pipeline, you can ensure that your application is deployed quickly, efficiently, and with minimal hassle. This guide has walked you through the steps to create a pipeline in Gitlab, with code examples.

Using CI/CD pipelines in Kubernetes explained

Building efficient development pipelines in Kubernetes requires the right tooling, a lot of planning, and a good understanding of your development processes.

To quickly build and deliver robust products and benefit from automation and efficient collaboration, the software team relies on continuous integration/continuous delivery (CI/CD) pipelines. Implementing CI/CD for cloud native applications makes delivery cycles more robust while streamlining the development and deployment workflow.

Let’s talk about the key components of a CI/CD pipeline, how to optimize these pipelines and some recommended best practices and tools.

What Makes an efficient CI/CD Pipeline

The Kubernetes platform and CI/CD workflows both aim to improve software quality, as well as automate and boost development velocity. So companies benefit from having CI/CD pipelines to use with Kubernetes.

The following are some key components of a Kubernetes-based CI/CD pipeline:

  • Containers help achieve encapsulation of application components while enabling seamless integration through runtimes.
  • Operating clusters deploy the containers for your software build once the CI/CD tool approves the containers.
  • Configuration management stores all details related to the infrastructure setup and identifies any newly introduced change in the system.
  • A version control system (VCS) is a unified source code repository that maintains code changes. This generates the trigger for a CI/CD tool to start the pipeline whenever a new change is pushed into its repository.
  • Image registries store container images.
  • Security testing and audits maintain the equilibrium between rapid development and security of the application by ensuring the pipelines are free from potential security threats.
  • Continuous monitoring and observability allow developers to obtain actionable insights and metrics by providing complete visibility into the application life cycle.

Key Considerations to Make Your Pipeline Effective

CI/CD sits at the core of DevOps practice, enabling a sustainable model to streamline and accelerate production releases. A comprehensive understanding of the workflow is fundamental to building an effective CI/CD pipeline, along with evaluating the enterprise requirement to help choose the right framework.

Below are some key considerations for making your pipeline effective:

  • All-in-one CI/CD tool vs. case-specific solutions: Similar to the infrastructure setup, it is crucial to diligently assess the available CI/CD tools based on use cases, technical requirements and organizational goals.
  • On-premises vs. managed vs. hybrid CI/CD: Each CI/CD pipeline type has its own effectiveness, depending on your requirements and infrastructure. Factors that determine the type of CI/CD pipeline to choose include ease of use, ease of setup, infrastructure and operating system support.
  • Code testing and validation: An effective validation and automated testing framework is one of the core components of a CI/CD pipeline. This ensures a stable build with zero code-quality issues while highlighting potential failure scenarios.
  • Rollbacks: These help organizations redeploy the previous stable release of an application. Implementing a diligently planned rollback mechanism in CI/CD is vital to safeguarding the application in case of failure or security incidents.

Defining a Kubernetes-Based CI/CD Pipeline

While defining a Kubernetes-based CI/CD pipeline, you can go with one of the two major paradigms below.

Push-Based Pipeline

An external system like a CI pipeline generates build triggers to deploy the changes to the Kubernetes cluster following a commit to a version control system repository in a push-based pipeline. Kubernetes cluster credentials are exposed outside the domain of the cluster in such a model.

Pull-Based Pipeline

Kubernetes operators deploy the changes from inside a cluster whenever new images are pushed to the registry in a pull-based pipeline.

Some Best Practices

Here are some recommendations for building an effective Kubernetes CI/CD pipeline. These include some useful best practices.

Avoid Hardcoding Secrets and Configurations in Containers

You should store configurations in configmap and not hardcode them in the containers. This provides the flexibility of deploying the same container in different environments without making environment-specific changes to it.

It’s also recommended to keep secrets out of containers and encrypt and store them in Kubernetes Secrets. This prevents credentials from getting exposed through a version control system in a CI/CD pipeline.

Use Helm for Deployments

Use the Helm package manager for Kubernetes application deployments ​​to keep track of releases or logical groupings.

Enable Git-Based Workflows

To allow for all infrastructure configurations to be stored within git, CI/CD pipelines should follow a GitOps methodology. It makes infrastructure code more accessible to developers, letting them review the changes before they’re deployed.

Git also provides a unified source repository and snapshots of the cluster. These are easy for developers to refer to as needed and recover the application to the last stable state in the case of failure.

Use Canary/Blue-Green Deployment Patterns

Parallel to the running production instances, running a blue-green pattern of instances lets you test changes and switch over traffic when testing is complete, eliminating the need for downtime during deployment.

Cache and Reuse Container Images

Use caching and reuse features of Docker container images to minimize container build times and reduce the risk of introducing defects into the newly built container image.

Tools for Kubernetes CI/CD Pipelines

All-in-One CI/CD Tools

GitHub Actions is an open source CI/CD tool that supports automated build, test and deployment pipelines. It is the preferred CI/CD platform when the source code repository is GitHub.

GitLab CI/CD facilitates the continuous build, test and deployment of software applications without the need for third-party integration. Checkout our article on implementing a Gitlab pipeline for your project.

Jenkins (including Jenkins X) is an open source, automation server that promotes CI and CD in varying levels of cluster complexity, enabling developers to automate application build, test and deployment processes seamlessly across hybrid/multicloud setups. Jenkins X is an upgraded version that facilitates automated CI/CD for cloud native containerized applications and orchestration tools like Kubernetes or Docker.

Rancher Fleet is fundamentally a set of Kubernetes custom resource definitions (CRDs) and controllers that manage GitOps for a single Kubernetes cluster or a large scale deployment of Kubernetes clusters. It is a distributed initialization system that makes it easy to customize applications and manage HA clusters from a single point.

CI Tools

Circle CI is a cloud-based CI tool that uses an API to facilitate automatic Kubernetes deployments. It is intensely focused on testing the new commit before deploying via various methods like unit testing, integration testing, etc. Because of its features for implementing complex pipelines with configurations like caching and resource classes, it is one of the most popular lightweight integration tools for a Kubernetes ecosystem.

Drone CI is an open source CI tool built entirely on Docker that uses a container-first approach. The plugins, components and pipeline stages of Drone are deployed and executed as Docker containers. The platform offers a wide range of flexibility for using different tools and environments for the build, but you have to integrate it with a git repository.

CD Tools

Spinnaker is an open source continuous delivery tool that integrates with multiple cloud providers. Since the platform does not rely on a GitOps model, config files can be stored in the cloud provider’s storage.

Argo CD is a declarative GitOps continuous delivery tool that is lightweight, easy to configure and purpose-built for Kubernetes. The platform considers git the source of truth, which enhances security, making access control and permission management easier to administer.

Automation and Infrastructure Configuration Tools

Terraform by Hashicorp is an open source Infrastructure as Code tool that facilitates DevOps teams’ ability to provision and manage infrastructure programmatically via configuration files.

Red Hat Ansible is an open source automation platform that enables automation for provisioning, configuration management and infrastructure deployment across cloud, virtual and on-premises environments.

Salt by Saltstack contains a robust and flexible configuration management framework, which is built on the remote execution core. This framework executes on the minions, allowing effortless, simultaneous configuration of tens of thousands of hosts, by rendering language specific state files. Unlike Ansible, Salt is agentless, relying instead on secure shell (SSH) connections to complete tasks. For a security architect, Salt is a gem!

Collaboration and Issue Management Tools

Jira is implemented by teams for software collaboration, defect tracking and work management. The tool offers customizable features like an intuitive dashboard, optimized workflows, efficient search, filtering and defect management. Jira is purpose-built to support various use cases of project management, such as capturing requirements, test case management and tracking tasks in real time.

Zendesk is a cloud-based customer support platform that enables an organization to engage with its client through different collaboration channels, including phone, email, chat and social media. Zendesk provides one easy-to-use platform for cross-functional collaboration and customer communications, thereby helping organizations to better manage customer queries and respond quickly.

Security

Open Policy Agent (OPA) is an open source policy engine that supports a high-level declarative language that lets developers specify Policy as Code. The platform is built to impose granular-level policies on different components, including CI/CD pipelines, microservices, Kubernetes clusters, etc.

Kubewarden is an open source policy engine simplifying the adoption of policy-as-code. It does not require any domain specific knowledge or new language constructs and can take existing policies, compile into WebAssembly and deploy into existing pipelines using existing processes.

Kube-bench is an open source tool used to run the CIS Kubernetes Benchmark test on Kubernetes clusters. This ensures that the Kubernetes cluster is secure and deployed according to the security recommendations in the benchmark document.

SUSE NeuVector is a fully open source end to end cloud native security platform to implement zero-trust security in containerized environments. With full support for Openshift, Kubernetes, and simple containerized workloads, SUSE NeuVector allows for complete visibility into your cloud-native network and will prevent any communication not explicitly required for an application or workload to function.

Monitoring Tools

Foresight is an observability product for CI pipelines and tests that enable secure, real-time monitoring of CI/CD pipelines. In addition to tracking metrics, traces and logs, the platform offers live debugging capabilities to facilitate quicker resolution of failures.

Prometheus/Grafana are open source, event-monitoring tools that implement a high-dimensional data model and store metrics along with timestamps in a time-series database. Prometheus ships with a flexible query language and is one of the most popular alerting systems for complex Kubernetes clusters. Based on metrics generated by Prometheus, Grafana offers built-in visualization support for efficient querying and analysis.

Summary

Delivering high-quality software at speed is not easy to sustain and scale. If you develop modern applications today, CI/CD sits at the heart of your software development process because it offers agility, reduces risks of production recessions and ensures quality. It is often considered critical to build an effective CI/CD pipeline for rapid workflow execution. Doing so requires diligent technical analysis, a generous amount of planning and choosing the right set of tools.

Picture showing tools in a circle

7 SRE tools to know today

As an SRE or platform engineer, you’re likely constantly looking for ways to streamline your workflow and make your day-to-day tasks more efficient. One of the best ways to do this is by utilizing popular SRE or DevOps tools. In this post, we’ll take a look at 7 of the most popular tools that are widely used in the industry today and explain their value in terms of how they can help make you more efficient in your day-to-day tasks.

  1. Prometheus: Prometheus is a popular open-source monitoring and alerting system that is widely used for monitoring distributed systems. It allows you to collect metrics from your services and set up alerts based on those metrics. Prometheus is known for its simple data model, easy-to-use query language, and powerful alerting capabilities. With Prometheus, you can quickly and easily identify issues within your systems and be alerted to them before they become a problem.
  2. Grafana: Grafana is a popular open-source visualization tool that can be used to create interactive dashboards and charts based on the metrics collected by Prometheus. It allows you to easily view the health of your systems, identify trends, and spot outliers. With Grafana, you can quickly and easily identify patterns and trends within your data, which can help you optimize your systems and improve their performance.
  3. Kubernetes: Kubernetes is an open-source container orchestration system that allows you to automate the deployment, scaling, and management of containerized applications. It helps you to define, deploy, and manage your application at scale, and to ensure high availability and fault tolerance. With Kubernetes, you can automate many routine tasks associated with deploying and managing your applications, which frees up more time for you to focus on other important tasks.
  4. Ansible: Ansible is an open-source automation tool that can be used to automate the provisioning, configuration, and deployment of your infrastructure. Ansible is known for its simple, human-readable syntax and its ability to easily manage and automate complex tasks. With Ansible, you can automate the provisioning and configuration of your infrastructure, which can help you save time and reduce the risk of errors.
  5. Terraform: Terraform is a popular open-source tool for provisioning and managing infrastructure as code. It allows you to define your infrastructure as code and to use a simple, declarative language to provision and manage resources across multiple providers. With Terraform, you can automate the process of provisioning and managing your infrastructure, which can help you save time and reduce the risk of errors.
  6. Jenkins: Jenkins is an open-source automation server that can be used to automate the building, testing, and deployment of your software. It provides a powerful plugin system that allows you to easily integrate with other tools, such as Git, Ansible, and Kubernetes. With Jenkins, you can automate many routine tasks associated with building, testing, and deploying your software, which frees up more time for you to focus on other important tasks.
  7. GitLab: GitLab is a web-based Git repository manager that provides source code management (SCM), continuous integration, and more. It’s a full-featured platform that covers the entire software development life cycle and allows you to manage your code, collaborate with your team, and automate your pipeline. With GitLab, you can streamline your entire software development process, from code management to deployment, which can help you save time and reduce the risk of errors.

These are just a few examples of the many popular SRE and DevOps tools that are widely used in the industry today.

Here’s to devops…a poem

In devops, we're constantly on call 
Our work is never done, no matter how small 
We're always ready to troubleshoot and fix 
Our skills are diverse, our knowledge is mixed
We're agile and flexible, always adapting 
We're proactive, we're never static 
We're experts in automation and efficiency 
We're the bridge between development and IT
We're passionate about our craft 
We strive for continuous improvement, it's what we're after 
We're the glue that holds everything together 
We're the unsung heroes, working in all kinds of weather
So here's to devops, the backbone of technology 
We may not always get the recognition, but we do it proudly 
We're a vital part of the team, and we know our worth 
We're the devops engineers, bringing stability to this earth

AWS EC2 Spot – Best Practices

Amazon’s EC2 has several options for running instances. On-demand instances is what would be used by most. Reserved instances are used by those who can do some level of usage prediction. Another option which can be a cost saver is using Spot instances. Amazon claims savings up to 90% off regular EC2 rates using Spot instances.

AWS operates like a utility company as such it has spare capacity at any given time. This spare capacity can be purchased through Spot instances. There’s a catch, though. With a 2 minute warning, Amazon can take back that “spare capacity” so using Spot instances needs to be carefully planned. When used correctly Spot instances can be a real cost-saver.

When to use Spot instances

There is a fairly broad set of use cases for using Spot instances. The general consensus is simply containerized, stateless workloads, but in reality there’s a lot more.

  • Distributed databases – think MongoDB or Cassandra or even Elasticsearch. These are distributed so losing one instance would not affect the data; simply start another one
  • Machine Learning – typically these are running training jobs and losing it would only mean the learning stops until another one is started. ML lends itself well to the Spot instance paradigm
  • CI/CD operations – this is a great one for Spot instances
  • Big Data operations – AWS EMR or Spark are also great use cases for Spot instances
  • Stateful workloads – even though these applications would need IP and data persistence, some (maybe even all) of these may be candidates for Spot instances especially if they are automated properly.

Be prepared for disruption

The primary practice for working in AWS in general, but also working with Spot instances is be prepared. Spot instances will be interrupted at some point when it’s least expected. It is critical to create your workload to handle failure. Take advantage of EC2 instance re-balance recommendations and Spot instance interruption notices.

The EC2 re-balance recommendation will notify of an elevated risk of Spot instance interruption in advance of the “2 minute warning”. Using the Capacity Rebalancing feature in Auto-scaling Groups and Spot fleet will provide the ability to be more proactive. Take a look at Capacity Rebalancing for more detail.

If the workloads are “time flexible” configure the Spot instances to stop or hibernate vs terminated when an interruption occurs. When the spare capacity returns the instance will be restarted.

Use the Spot instance interruption notice and the Capacity rebalance notice to your advantage by using the EventBridge to create rules to gracefully handle an interruption. One such example is outlined next.

Using Spot instances with ELB

In a lot of cases Elastic Load Balancer (ELB) is used. Instances are registered and de-registered to the ELB based on health check status. Problem with Spot instances is the instance do not de-register automatically so there may be some interruption if the situation is not handled properly.

The proper way would be to use the interruption notice as a trigger to de-register the instance from the ELB. By programmatically de-registering the Spot instance prior to termination traffic would not be routed to the instance and no traffic would be lost.

Easiest way is to use a Lambda function to trigger based on a Cloudwatch instance termination notice. The Lambda function simply retrieves the instance ID from the event and de-registers the instance from the ELB. As usual, Amazon Solution Architects showed how to do it on the AWS Compute Blog.

Keep your options open

The Spot capacity pool consists of a set of unused EC2 instances with the same instance type (t3.micro, m4.large, etc) and Availability Zone (us-west-1a). Avoid getting too specific on instance types and what zone they use. For instance, avoid specifically requesting c4.large if running the workload on a m5, c5, or m4 family would work the same. Keep specific needs in mind, vertically scaled workloads need more resources and horizontally scaled workloads would find more availability in older generation types as they are in less demand.

Amazon recommends being flexible across at least 10 instance types and there is never a need to limit Availability Zones. Ensure all AZs are enabled in your VPC for your instance to use.

Price and capacity optimized strategy

Take advantage of Auto Scaling groups as the allocation strategies will enable provisioning capacity automatically. The price-capacity-optimized strategy in Spot Fleet due to how the instance capacity is sourced from pools with optimal capacity. This strategy will reduce the possibility of having the Spot instance reclaimed. Dig into the Auto Scaling User Guide Spot Instances section for more detail. Also take a look at this section which describes when workloads have a high cost of interruption.

Think aggregate capacity

Instead of looking at individual instances, Spot enables a more holistic view across units such as vCPUs, network, memory, or storage. Using Spot Fleet with Auto Scaling Groups allows for a higher level view enabling the concept of “target capacity”. Automating the request for more resources to maintain the target capacity of a workload enables considerable flexibility.

Other options to consider

Amazon has a considerable number of services which can be integrated with Spot instances to manage compute costs. Used effectively these services will allow for more flexibility and automation eliminating the need to manage individual instances or fleets. Take a look at the EC2 Spot Workshops for some ideas and examples.

Devops Toolkit for Automation

In the DevOps methodology automation is likely the most important concept. Use “automate everything” as a mantra daily.

Image by Michal Jarmoluk from Pixabay

As an “operator” working in a DevOps role good tools are a necessity. Tools which allow for automating most everything is crucial to keeping up with the vast amount of changes and updates created in a Agile development environment.

Using the same tools your counterparts on the team use will allow for expediting the learning process. In a lot of cases developers use a IDE (Integrated Development Environment) of some sort. Visual Studio Code comes to the forefront, but some ‘hardcore’ or ‘old school’ developers still use Emacs or even Vim as their development tool of choice. There are many out there and each has its pros and cons. Along with a IDE there will be the need for extensions to make things simpler. Let’s outline a few and focus on Visual Studio Code as the tool of choice.

Visual Studio Code is available for most of the commonly used platforms. It has a ton of extensions, but as a “DevOps Engineer” you’ll need a few to make your life easier. First and foremost you’ll want extensions to make working with your favorite cloud provider easier. There are plugins for AWS, GKE, and AKS as well as plugins for yaml, Kubernetes, and Github.

Another extension necessary for container development is the Remote Development Extension Pack. This extension provides the Dev Containers extension allowing for the opening of files and folders inside a container. It also provides a SSH extension to simplify access to remote machines. The Dev Containers extension will want to use Docker Desktop, but a better alternative is Rancher Desktop.

Rancher Desktop is another superb tool for several reasons.

  • 100% open source
  • Includes K3s as the Kubernetes distribution
  • Can use with dockerd (moby) or containerd
  • Basic dashboard
  • Easy to use

To get started with it, download Rancher Desktop and install on your favorite platform. Follow the installation instructions and once installed go to the preferences page and select “dockerd (moby)” as shown below.

Rancher Desktop Kubernetes Settings

Now that you have Rancher Desktop installed as well as Visual Studio Code with all of the extensions take some time to get familiar with it. Best to start with your github account and create or fork a repository to work with inside Visual Studio Code. Reading through the various getting started docs yields hours of things to try or work with to learn.

To get started with your Rancher Desktop cluster simply click on the Rancher Desktop icon. In most windowed environments there’s a icon in the “task bar”.

Click on the Dashboard link to get access to view the K3s cluster installed when Rancher Desktop started.

Another way to access the cluster is to use kubectl. A number of utilities were installed to ~/.rd/bin. Use kubectl get nodes to view the node(s) in your cluster or use kubectl get pods -A to view all of the pods in the cluster.

Many utilities exist to view/manage Kubernetes clusters. Great learning experiences come from experimentation.

A lot was accomplished in this post. From a bit of reading to manipulating a Kubernetes cluster there is a lot of information to absorb. Visual Studio Code will be the foundation for a lot of the work done in the DevOps world. Containers and Kubernetes will be the foundation for the execution of the work created. This post provided the building blocks to combine the Dev and the Ops with what’s needed to automate the process.

Next up…building a simple CI/CD pipeline.

Getting started in DevOps

Getting started in DevOps doesn’t have to be hard.

Image by Dirk Wouters from Pixabay

How do we get started…starting with some assumptions.

  1. You understand how to install and manage a Kubernetes cluster.
  2. You understand how to ‘git’ around. (heh…like the pun?)
  3. You know how CI/CD pipelines work.
  4. You understand some development. Or at least you know how to get around tools like VSCode.

There’s plenty of knowledge to be found here so let’s get started.

In most cases companies needing people who understand DevOps best practices are either starting on or already executing a Digital Transformation journey. These journeys are just that, a journey so grab a seat, buckle up, and enjoy the ride. This particular ride involves a lot of buzzword bingo games. There will be plenty of opportunity for playing that game later.

Getting started on the journey

The first part of every journey is preparing for it. It helps to learn a bit more about the destination before embarking on the actual journey to that destination so watch for the buzzwords. The first thing to note is a lot of enterprises have a lot of technical debt. Suffice to say there will be a lot of work for far more developers than there are resources for said developers. From ancient Microsoft .net work to crufty java, there’s plenty of history in those binaries. One of the goals may be to modernize these applications. The fabulous book, “The Phoenix Project” describes how “Phil” takes a over budget and behind schedule modernization project to deployment utilizing effective collaboration and communication, crowdsourcing, and the “Three Ways”.

Hopefully “The Phoenix Project” helped to frame what is in store for embarking on the adventure into DevOps. The next steps are to put in practice some of the constructs outlined. One of the key tenants of the book was to ensure the “pipeline” has no obstructions as one single slow down will slow the entire line of work. This slow down will create bottlenecks which, in turn, will create a ripple effect on the entire process. These “pipelines” in a cloud native development world are part of the CI/CD process or continuous improvement, continuous development pipeline.

Other takeaways

Gene Kim outlined a few other takeaways in “The Phoenix Project” worth noting. The first one came from the need to work in smaller groups. Jeff Bezos is credited with creating the “Two Pizza Team” where the teams are limited in size (consume 2 pizzas per team). This is how a lot of the innovation came from within Amazon. Small, competitive teams who communicated very well. This small team concept leads to another concept of “microservices”.

Instead of monoliths where everything runs together, microservices breaks each service into a functional unit. Microservices are focused on putting services into the smallest possible unit of work. With smaller units of work comes smaller changes which can be committed and tested faster as well as tested locally in most cases. Microservices will be a key concept to note on this digital transformation journey. Microservices create the need for cross functional teams where communication and collaboration is key. This is where the concept of DevOps comes into play. Employing the DevOps methodologies is crucial to the success of a transformative project.

Enterprises around the world have endured a massive sea of change in the years since the Covid-19 pandemic started. Even as companies were beginning to embrace the concepts of digital transformation, Covid-19 forced an acceleration of this transformation if the enterprise wanted to survive. Embracing remote work was key to survival.

This post was simply an introduction. With the key concepts outlined subsequent related posts will focus more on a technical guide to the technology underneath embracing a DevOps methodology. With DevOps many tools exist to help in the many facets including how to create a culture within an organization capable of embracing the change needed to adopt ongoing transformation to adapt to even the slightest change in your organizations market.

Next up…the introduction of a Podman setup to start down the path of using, managing, and orchestrating containers.

Simplify using Podman instead of Docker

At this point most everyone using containers know of Docker, but is Docker right for your workload? Maybe not. If you plan on using Kubernetes to run your “cloud native” workloads, then it may be worthwhile to use a tool which was designed to run Kubernetes workloads originally. Another reason would be Podman is daemonless, whereas docker wants to control everything docker. Podman does not need root access to run containers. One final reason is Docker is a “one-stop” shop where Podman is modular. You install and use what you need with Podman like buildah to build images. Podman ends up being lighter weight and leaves the heavy lifting to other tools while maintaining OCI compliance and being more secure overall.

Ok so you are now convinced to move into the growing mainstream using Podman. Since you’ve been running Docker for a while you realized that you can add yourself to the docker group and all is good. It’s not so easy with Podman which is a REALLY good thing and makes Podman more secure. Let’s talk about about the why and we’ll get to the how momentarily.

Podman works a little different than Docker (shocker). Podman uses a subordinate system which is assigned to the user at runtime. With that being said, Podman would end up using more UIDs and SUBUIDs than Docker (docker uses the existing system for it’s UIDs). This means we need to “pre-assign” a block for Podman to use and we probably need to increase the defaults to support those additional UIDs and SUBUIDs.

Installing Podman is quite simple. Podman is available for most OS’s and architectures. For SUSE Linux, simply ‘zypper in podman’ will install it. You will want to also add slirp4netns using ‘zypper in slirp4netns’ (you may need to add the container module using ‘SUSEConnect -p sle-module-containers/15.4/x86_64’ replacing 15.4 with your SLE version and x86_64 with your architecture).

With Podman installed we now need to grant the user we want to run Podman with a block of SUBUIDs and SUBGIDs which may be outside what is normally used. Let’s use 200000-265536. Run the command:

sudo usermod –add-subuids 200000-265536 –add-subgids 200000-265536 $USER

Where $USER is “your user” or the user you want to run Podman commands (remember we’re avoiding sudo or root here).

Now you need to add more namespaces since the user may not have enough by default. Check the number available.

Use sysctl –all –pattern user_namespaces and if it is the default of 1000 you will want to increase that number.

Use sudo nano /etc/sysctl.d/userns.conf

Add user.max_user_namespaces=28633 to bump the available namespaces

Use sudo sysctl -p /etc/sysctl.d/userns.conf to load the new setting

And use sysctl –all –pattern user_namespaces to verify what you added.

Now it will be necessary to configure user networking. To do this we need to enable slirp4netns (it was installed earlier). To enable all of the default settings, reboot your node.

That’s it! A little more involved than using docker without sudo by adding your user to the docker group, but you are now using a more modern and secure tool for managing your containers!

The journey

My journey into this space began a very long time ago so I’ll skip all the gory details and jump into how I managed to get to this point. The gist of it is I was a “sysadmin” running IT for what was at the time a very large systems integrator. We had ~200 or so people and processed roughly 300 orders per day. It was a “paperless” warehouse running on OS/2. Told you it was “long ago”. Let’s fast forward…

Started working for a company who was starting their transformation journey (this is well before Covid) and had been using large numbers of virtual machines. I was brought in because they had an outage due to a hardware failure and new management decided it was best to take advantage of AWS. The current AWS infrastructure was created by the old school datacenter admins so it, too was a catastrophe waiting to happen.

I had been working with AWS for a while so I had been taking my knowledge of puppet and applying it to help automate some of the mundane tasks. The old school devs were used to using mercurial so I encouraged them to pull some of the tasks created in puppet into their code and got them started deploying their apps on their own to AWS. This was working.

Fast forward a bit and the dev teams had evolved to a really nice Agile based setup. I had spent a ton of time learning how to manage pipelines, transitioning from puppet to terraform, and had educated a lot of the newer operations folks on automating everything.

My journey is probably very similar to most. In my case I never really got into windows. I had started down the linux path very early in the big scheme of things and stuck with it. This really helped when it came to running and managing things in the cloud. Transitioning all of the various scripting languages was pretty straightforward because I had a good grasp on how to script. I had bash scripts for everything and that helped tremendously when I dove into Terraform and other tools. Plus I was very comfortable with the command line.

The one thing I suggest is read, read, read. O’Reilly is a great resource. No matter where you are coming from the most important thing to remember is look at the box and think INSIDE of it. Never try to apply knowledge from what you are currently doing into what you want to do. What I mean by this is managing VMs is very different from managing container images, but they are the same. Yea…I know confusing, but so is “cloud-native”.

I did it. You can, too.