Organizations are rapidly moving their Kubernetes applications to production to accelerate feature velocity and drive digital transformation and business growth. Our latest State of Kubernetes Security survey report shows that companies have standardized on Kubernetes, and this rapid adoption offers equal parts promise and peril. Promise, in the form of infrastructure that enables far greater inherent security than ever before. And peril, as companies struggle to overcome a skills gap and configure the technology in the most secure manner.

Kubernetes workloads – often deployed across varying environments (cloud, on-prem, hybrid) – require a security approach that is portable; protects the full container life cycle; and leverages Kubernetes’ rich context, native controls, and scalable policy enforcement to build a bridge between DevOps and Security.

The following six Kubernetes security use cases top the list of priorities for most organizations that we surveyed – follow the best practices gleaned from your peers and shared here to get your organization on the right track.

1. Runtime threat detection and response

According to our report, runtime is the life cycle phase that customers are most worried about, and more people consider runtime detection a “must have” than any others. The security goal in this phase is to detect and respond to malicious activity in an automated and scalable way while minimizing false positives and alert fatigue. Kubernetes offers rich declarative data around images and deployments that delivers valuable context when assessing runtime behavior. Leverage this context to more accurately differentiate between simple anomalies and true threats, and use Kubernetes-native enforcement capabilities to mitigate runtime threats in the most automated and scalable manner.

2. Compliance

DevOps moves fast and relies on automation for continuous improvement, so organizations need a compliance solution built to complement – not inhibit – the pace of business. You need to not only adhere to industry compliance requirements but also show evidence of that compliance. You should be able to show which clusters, nodes, or namespaces are compliant with all the individual controls relevant in container and Kubernetes environments from frameworks including CIS benchmarks for Docker and Kubernetes, PCI, HIPAA, and NIST SP 800-190. And it should be dead simple to run on-demand compliance checks and export evidence of compliance.

3. Configuration management

Misconfiguration poses the greatest security risk to containers and Kubernetes, with 67% of survey respondents experiencing a K8s misconfiguration in the last 12 months. In today’s DevOps-driven environment, configuration management must be as automated and streamlined as possible for it to not slow down application development and deployment. It should be comprehensive, covering containers, Kubernetes, and all their configurable components, including:

RBAC
Secrets
Network policies
Privilege levels
Resource limits/requests
Read-only root file systems
Annotations, labels
Sensitive host mount and access
Image configuration, including provenance

4. Vulnerability scanning and management

Most organizations start with vulnerability management – the challenge is to quickly move beyond the limited value provided by image scanning. Organizations must also identify vulnerabilities in Kubernetes, and they need a way to quickly pinpoint newly discovered vulnerabilities in already running deployments. Start with vulnerability management, but demand more than image scanning for this use case.

5. Visibility

Gaining visibility into your container and Kubernetes environments is at the root of being able to properly secure that environment. Only when your security tooling is fully embedded into Kubernetes can you understand your cloud-native infrastructure, including images, containers, pods, namespaces, clusters, and network policies. You need insights into how each is configured and whether they’re compliant with industry standards and your internal security policies.

6. Network segmentation

Containers pose a unique networking challenge because containers communicate with each other across nodes and clusters (east-west traffic) and outside endpoints (north-south traffic). Kubernetes provides built-in capabilities that enable network segmentation. Leverage those native controls to ensure consistent, portable, and scalable network segmentation regardless of your CNI plugin or Kubernetes distribution. Using the segmentation inherent in Kubernetes ensures that security and DevOps see and act on a single source of truth and consistent information to restrict access and reduce the blast radius.

The Database: DevOps’s Forgotten Bottleneck

Organisations investing heavily in CI/CD pipelines, automated testing, and cloud-native infrastructure often overlook one critical component: the database. When database changes are managed manually, reviewed out-of-band, or simply excluded from the deployment pipeline, they become a chokepoint that erodes every efficiency gain made elsewhere in the delivery process.

The 2018 Accelerate State of DevOps Report — produced by DORA (DevOps Research and Assessment) — makes this explicit. Elite-performing organisations in the report deployed code 46 times more frequently than low performers, recovered from failures 2,604 times faster, and had a 7 times lower change failure rate. Critically, their lead time from committing a change to deploying it was under one hour, compared to one to six months for the lowest-performing cohort. Excluding the database from the DevOps workflow is one of the fastest ways to land in that low-performing bracket.

The Developer–DBA Divide

Part of the problem is cultural and historical. Application developers are focused on shipping features quickly. Database administrators (DBAs) are responsible for keeping business-critical data available, consistent, and safe. These priorities have traditionally pulled in opposite directions, breeding mutual suspicion: developers worry that DBAs will block or delay releases; DBAs worry that untested schema changes will bring down production databases.

The good news is that attitudes are shifting. Redgate’s 2018 State of Database DevOps Survey found that 58% of respondents described collaboration between developers and DBAs as either good or great — a sign that the industry recognises shared goals matter more than functional silos.

So how do you build that collaboration and make the database a first-class citizen in your DevOps process? The DORA report points to four practical focus areas.

1. Ensure Consistency by Treating Database Changes Like Code

Database development today is roughly where application development was a decade ago: changes are often made manually, undocumented, and outside any formal pipeline. The solution is to apply the same discipline that transformed application delivery.

• Version control everything. Store all schema changes, stored procedures, and seed data as SQL scripts in your version control system (Git, SVN, etc.), alongside application code. This creates a single source of truth and a full audit trail.
• Apply configuration management principles. Treat the database schema as infrastructure. Define the desired state, use tooling to detect drift, and automate remediation.
• Integrate database changes into CI/CD pipelines. Run schema migrations as a pipeline stage — building, validating, and deploying them with the same gates (automated tests, peer review, approval workflows) applied to application code.
• Use dedicated database DevOps tooling. Tools such as Flyway, Liquibase, and Redgate’s SQL Change Automation are designed to automate and version database deployments in a pipeline-friendly way.

Consistency means a change applied in development travels through test, staging, and production environments in a predictable, repeatable way — with no manual steps and no surprises.

2. Use Monitoring and Observability to Learn Continuously

Visibility is a prerequisite for improvement. In a database-inclusive DevOps workflow, this means two complementary capabilities.

Monitoring

Pre-defined metrics — query latency, replication lag, connection pool saturation, deadlock rates, index usage — need to be captured and surfaced to the whole team, not just the DBA. Dashboards should be tied to business SLAs so that a spike in database response time is immediately understood in terms of end-user impact, not just raw infrastructure numbers.

Observability

The DORA report highlights observability as a distinct and newer capability. Where monitoring answers the questions you thought to ask in advance, observability lets you ask questions you did not anticipate — exploring system behaviour through logs, traces, and events to diagnose novel failure modes. The report found that organisations with both monitoring and observability in place were 1.3 times more likely to be among the top DevOps performers.

Equally important is what you do with the data. DORA found that teams running structured post-incident reviews and using the findings to drive continuous improvement were more likely to rank among elite performers. Blameless retrospectives applied to database incidents — not just application outages — accelerate learning across the whole team.

3. Build a Common, Open Culture

One of the more counterintuitive findings in the DORA report is that industry sector is not a reliable predictor of DevOps performance. High performers exist in heavily regulated industries — government, financial services, healthcare — just as much as in fast-moving retail or technology companies. The differentiator is not what business you are in, but how your organisation behaves.

Culture shapes everything. High-performing teams share several traits:

• Openness to change. They treat the current process as a starting point, not a fixed constraint.
• Psychological safety. Team members can surface problems — including database risks — without fear of blame.
• Shared ownership. No single team owns quality or reliability in isolation; everyone is accountable for the outcome.
• Continuous learning. Skills are developed across boundaries — developers learn database fundamentals; DBAs learn deployment automation.

Leadership plays a decisive role here. Building trust, granting teams meaningful autonomy, and communicating clearly why database changes are part of the shared mission — not a bureaucratic gate — are all leadership responsibilities, not technical ones.

4. Encourage Collaboration and Shared Ownership Across the Organisation

The practical expression of that culture is how developers and DBAs actually work together day to day. Several patterns have emerged in organisations that have successfully bridged the divide.

• Embed DBAs in DevOps teams. Rather than DBAs sitting in a separate team that reviews requests on a ticket-by-ticket basis, some organisations assign a DBA as an advisor to the development team around major releases. Their role shifts from gatekeeper to coach — helping developers write migration scripts that perform safely at scale, reviewing schema designs early in the sprint rather than at deployment time.
• Shared tooling and pipelines. When developers and DBAs use the same version control repositories, the same pipeline stages, and the same deployment scripts, there is a natural forcing function for conversation and shared understanding.
• Pair reviews on database changes. Pull request reviews on schema migrations that include a DBA or a developer with database expertise catch problems earlier and spread knowledge across the team.
• Database changes in sprint planning. Including database migration tasks in sprint planning — estimated, prioritised, and tracked alongside feature work — prevents them from becoming a last-minute surprise at deployment time.

Summary: The Database Is Not Optional in DevOps

The DORA findings are clear: elite DevOps performance requires the database to be part of the delivery pipeline, not an afterthought managed outside it. The four areas outlined above — consistency through version-controlled, automated database deployments; visibility through monitoring and observability; an open, learning culture; and genuine developer–DBA collaboration — provide a practical roadmap for any team looking to close the gap.

For DBAs, this shift is also an opportunity. Moving from a reactive, ticket-driven role to an embedded advisor and automation specialist is a significant career evolution — one that makes the DBA function more visible, more valued, and more directly connected to business outcomes.

Organisations that still treat developers and DBAs as separate silos will continue to find that their database is the ceiling on their DevOps ambitions. Breaking down that barrier is not just a process improvement — it is a competitive necessity.

No single transformation path fits every organization, but the research found that these five capabilities are essential at every stage of DevOps maturity. Teams that embed them early create the conditions for continuous improvement, faster delivery, and stronger cross-functional collaboration.

1. Monitoring and Alerting Are Configurable by the Team Operating the Service

Effective DevOps requires both empowerment and accountability at the team level. High-performing organizations give individual product and service teams the authority to define their own monitoring thresholds, alerting rules, and observability criteria for the services they run in production—rather than delegating that responsibility to a central operations group.

When teams own their own monitoring configuration, several things happen naturally:

• Faster incident detection: The people who built the service know which signals matter most and can tune alerts accordingly.
• Shared metrics culture: Teams can publish dashboards and share measurement approaches across the organization, promoting continuous improvement.
• Systems thinking: Visibility into how one service affects others fosters cross-team collaboration and a broader understanding of the production environment.

Tools such as Prometheus, Datadog, Grafana, and PagerDuty all support team-level configuration of alerts and dashboards. The tooling matters less than the organizational decision to give teams genuine ownership of what they measure.

2. Deployment Patterns Are Reused Across Applications and Services

Reinventing the deployment process for every application is expensive and error-prone. Top-performing DevOps organizations standardize on reusable deployment routines, pipeline templates, and tooling that any team can adopt and extend.

According to the Puppet report, 46% of high-performing DevOps organizations reported always reusing deployment patterns, compared to just 2% of lower-performing organizations. That gap is significant: standardized deployment patterns reduce the cognitive overhead of shipping software, make onboarding new engineers easier, and create a shared vocabulary for discussing deployments across teams.

In practice, reusable deployment patterns might take the form of:

• Shared CI/CD pipeline templates in tools like Jenkins, GitLab CI, or GitHub Actions
• Standardized Helm charts or Kubernetes manifests for containerized workloads
• Internal deployment libraries or platform engineering products that abstract infrastructure complexity

3. Testing Patterns Are Reused Across Applications and Services

The same logic that applies to deployment applies equally to testing. High-performing organizations do not ask every team to define its own approach to unit testing, integration testing, and end-to-end validation from scratch. They build and share reusable testing patterns that encode organizational knowledge about how to verify software quality reliably.

The Puppet report found that high-performing organizations are 44 times more likely to use repeatable testing patterns than lower-performing peers. Reusable test frameworks reduce the barrier to achieving meaningful test coverage, make test results comparable across services, and give platform and quality engineering teams a lever to raise the quality floor for the whole organization at once.

Common implementations include shared test harnesses, contract testing libraries (for microservices), and standardized policies for code coverage thresholds enforced at the pipeline level.

4. Teams Contribute Improvements to Tooling Owned by Other Teams

In siloed organizations, tooling improvements stay within the team that built the tool. Engineers in other teams who identify a bug or a missing feature either work around it or duplicate effort by building their own version. This is one of the most persistent anti-patterns in enterprise software delivery.

High-performing DevOps organizations break down that silo by creating a culture—and the technical infrastructure—for cross-team tooling contributions. The Puppet report found that high performers are 44 times more likely to contribute improvements to tooling provided by other teams. Treating internal tools as internal open-source projects, with contribution guides, code review processes, and clear ownership, is one proven way to enable this behavior.

Platform engineering teams that operate internal developer platforms (IDPs) are well-positioned to formalize this practice. Exposing platform capabilities as versioned APIs or libraries with public repositories makes it straightforward for application teams to raise pull requests with improvements.

5. Configurations Are Managed by a Configuration Management Tool

Configuration management was one of the earliest technical practices associated with the DevOps movement, and it remains a reliable baseline indicator of organizational maturity. Managing infrastructure and application configuration through code—rather than manual, ad hoc changes—enables reproducibility, auditability, and faster environment provisioning.

The Puppet report found that 53% of high-performing organizations always use a configuration management tool, compared to 2% of lower-performing ones. Tools in this category include Puppet, Ansible, Chef, and SaltStack for infrastructure configuration, as well as approaches like GitOps (using tools such as Flux or Argo CD) for application configuration in Kubernetes environments.

The benefits compound over time: teams that manage configuration as code can spin up consistent test environments on demand, reduce configuration drift between staging and production, and trace every infrastructure change back to a specific commit and author.

Putting the Five Practices Together

These five practices are mutually reinforcing. Configuration management makes reusable deployment and testing patterns easier to implement consistently. Cross-team tooling contributions spread those patterns faster. Team-owned monitoring closes the feedback loop so that each release cycle generates actionable data for the next one.

Organizations starting a DevOps transformation often look for a single lever to pull. The Puppet research suggests that sustainable improvement requires building all five capabilities in parallel, even if the initial implementations are modest. Start with configuration management and team-owned monitoring—both deliver value quickly and build the muscle memory for the collaborative practices that follow.

The statistics cited in this article are drawn from a Puppet State of DevOps report referenced in a TechRepublic article published in November 2018. Refer to Puppet’s annual State of DevOps Report series for the most current benchmarks.

Overview

Continuous Delivery with Docker and Jenkins by Rafal Leszko is a hands-on technical book aimed at developers and DevOps engineers who want to build production-grade CI/CD pipelines. It covers the full lifecycle from local development to automated deployment, using Docker for containerization and Jenkins as the CI/CD orchestrator. For teams that have found other CI/CD books outdated or too abstract, this title offers a practical, current alternative.

What the Book Covers

Leszko starts by contrasting traditional software delivery methods with continuous delivery, making a case for CD as the more reliable and scalable approach. He then progressively builds on that foundation, covering:

• Docker fundamentals: What Docker is, how it works, and step-by-step installation and configuration instructions for all major operating systems.
• Jenkins setup: Installing and configuring Jenkins 2, including pipeline-as-code with Jenkinsfile.
• Automated testing: Integrating automated test stages into the pipeline.
• Configuration management with Ansible: Leszko covers Puppet, Chef, and Ansible as his top three configuration management tools, with a clear preference for Ansible due to its agentless architecture.
• Advanced pipeline patterns: Parallel pipeline steps, database management, and migration strategies within a CD workflow.
• Docker Swarm: Server clustering using Docker swarm mode and the docker stack command for orchestrating multi-container applications.
• Zero-downtime deployments and rollbacks: Strategies to keep applications available during updates and recover quickly from failed releases.

Strengths

The book’s greatest asset is its accessibility. Each chapter opens with foundational concepts before advancing to practical implementation, making it usable for readers who are new to containers or CI/CD. The writing style is described as clear and direct, avoiding jargon where possible.

Beyond the basics, Leszko provides real-world examples and case studies to help readers optimize their pipelines rather than simply build them. The goal is for readers to finish the book capable of:

• Deploying applications using Docker Swarm clusters.
• Managing database migrations as part of an automated pipeline.
• Orchestrating and scaling multiple containers in production.
• Implementing rollback strategies to reduce deployment risk.

The book also argues that a well-structured CD pipeline reduces the resources required compared to ad-hoc or manual delivery approaches, a practical selling point for teams making a case for DevOps investment.

Limitations to Be Aware Of

The book’s configuration management coverage is narrow. Leszko focuses almost exclusively on Ansible and gives only brief mentions to Puppet and Chef. SaltStack, which offers both agentless and client-server modes and is a legitimate alternative to Ansible, is not discussed. Teams already using Salt or evaluating it will need to look elsewhere for guidance on integrating it into a Docker/Jenkins pipeline.

Similarly, the orchestration coverage centers on Docker Swarm. Readers who need to understand Kubernetes-based pipelines — which have become the dominant container orchestration platform since this book was published — should supplement this book with Kubernetes-specific resources.

Who Should Read It

This book suits a broad audience:

• Developers who want to understand how their code moves from commit to production.
• IT operations staff building or modernizing delivery pipelines.
• Engineering managers and architects who need a clear picture of CD principles before evaluating tooling choices.
• Teams new to Docker and Jenkins who want a single resource rather than piecing together blog posts and documentation.

Experienced DevOps practitioners who already run Docker and Jenkins in production may find the early chapters too introductory, but the advanced sections on parallel pipelines, zero-downtime deployments, and Swarm clustering may still offer value.

Verdict

Continuous Delivery with Docker and Jenkins is a well-structured, practical resource for teams adopting or maturing their CI/CD practices. Its hands-on approach, clear writing, and progression from basics to advanced topics make it accessible without being superficial. The main caveats are its narrow configuration management coverage and the fact that its orchestration content predates Kubernetes becoming the industry standard. If your stack aligns with Docker Swarm and Jenkins, this book delivers a thorough, actionable foundation.

Note: This tutorial is based on a TechTarget walkthrough originally published in 2017, using Chef client version 12.18.31 on CentOS Linux 7. Some tooling details (such as Chef DK packaging and commands) may differ in newer Chef versions. Always consult the official Chef documentation for current installation instructions.

Architecture Overview

A complete Chef environment typically consists of three components:

• Chef Server — the central repository for cookbooks, node data, and policy
• Workstation — the machine where you write and upload cookbooks using the knife CLI
• Managed Nodes — target machines where the Chef client applies configuration

To keep this tutorial self-contained, all three roles run on a single machine. Chef Zero, a lightweight in-memory Chef server included with Chef DK, replaces a full Chef Server for local development and testing.

Step 1: Install Chef Development Kit

Chef DK is a cross-platform package available from the Chef website. It bundles the Chef client, Chef Zero, the knife CLI, and supporting tools such as Test Kitchen and Berkshelf.

• macOS and Windows: Chef DK ships with a graphical installer.
• Linux (CentOS/RHEL): Download the RPM package, install it with rpm or yum, then verify the installation.

After installation, confirm that Chef is available by checking the version:

chef -v

Configure the Shell Environment

Chef DK installs its own Ruby runtime and tools into an isolated directory. To make them visible in your shell session, initialise the Chef shell environment:

eval "$(chef shell-init bash)"

On RHEL/CentOS 7 with Bash, the command above sets the correct PATH and environment variables for the duration of your session. Add it to your ~/.bashrc to make it persistent.

Install Git

Chef repositories are typically managed with Git. Install it with:

yum install git-all -y

No additional Git configuration is required for this tutorial.

Step 2: Generate a Chef Repository and Cookbook

Chef organises configuration instructions into cookbooks, which contain recipes. The chef generate command scaffolds the directory structure for you.

chef generate app myapp --email "yourmail@example.com"

This creates a myapp/ directory tree. The default recipe is located at:

myapp/cookbooks/myapp/recipes/default.rb

Listing 1: Initial default.rb Content

After generation, the file contains only a header comment block:

#
# Cookbook:: myapp
# Recipe:: default
#
# Copyright:: 2017, The Authors, All Rights Reserved.

Step 3: Write Your First Recipe

Chef recipes use a Ruby-based DSL built around resources — declarative descriptions of the desired state of a system component. Add the following resource declaration to the end of default.rb:

file '/tmp/cheffile.txt' do
  action :create
  content 'Chef example file'
end

This tells Chef to ensure that the file /tmp/cheffile.txt exists and contains the text Chef example file. If the file does not exist, Chef creates it. If it exists with different content, Chef updates it. This idempotent behaviour is a core principle of Chef configuration management.

Step 4: Run the Recipe with chef-client in Local Mode

From the directory containing default.rb, run:

chef-client --local-mode $(pwd)/default.rb

The --local-mode flag tells the Chef client to use Chef Zero as an in-process server rather than connecting to a remote Chef Server. This is ideal for development and testing.

Listing 2: chef-client Output

The output is verbose by design — Chef logs each action it takes. A successful run on CentOS 7 with Chef 12.18.31 produces output similar to the following:

[root@sander recipes]# chef-client --local-mode $(pwd)/default.rb
[2017-04-05T12:47:57+02:00] WARN: No config file found or specified on command line, using command line options.
[2017-04-05T12:47:57+02:00] INFO: Forking chef instance to converge...
Starting Chef Client, version 12.18.31
[2017-04-05T12:47:57+02:00] INFO: *** Chef 12.18.31 ***
[2017-04-05T12:47:57+02:00] INFO: Platform: x86_64-linux
[2017-04-05T12:47:57+02:00] INFO: Chef-client pid: 24793
[2017-04-05T12:48:15+02:00] INFO: Run List is []
[2017-04-05T12:48:15+02:00] INFO: Run List expands to []
[2017-04-05T12:48:15+02:00] INFO: Starting Chef Run for sander.example.com
...
Converging 1 resources
Recipe: @recipe_files::/home/user/Downloads/myapp/cookbooks/myapp/recipes/default.rb
  * file[/tmp/cheffile.txt] action create
    - create new file /tmp/cheffile.txt
    - update content in file /tmp/cheffile.txt from none to 2ccbda
    --- /tmp/cheffile.txt    2017-04-05 12:48:15.657202657 +0200
    +++ /tmp/.chef-cheffile20170405-24793-wufglh.txt 2017-04-05 12:48:15.655202665 +0200
    @@ -1 +1,2 @@
    +Chef example file
    - restore selinux security context
[2017-04-05T12:48:15+02:00] INFO: Chef Run complete in 0.194898281 seconds
Chef Client finished, 1/1 resources updated in 18 seconds

Key lines to note:

• “Converging 1 resources” — Chef found one resource to evaluate (the file resource).
• “create new file /tmp/cheffile.txt” — Chef created the file because it did not previously exist.
• “restore selinux security context” — On SELinux-enabled systems (like CentOS 7), Chef automatically restores the correct SELinux context after creating or modifying files.
• “1/1 resources updated” — All resources were successfully converged.

Step 5: Extend the Recipe — Installing and Starting a Service

Once you are comfortable with the basic workflow, you can manage packages and services. The following recipe snippet installs NGINX and ensures it is enabled and running:

package 'nginx' do
  action :install
end

service 'nginx' do
  action [:enable, :start]
end

Add these blocks to default.rb after the file resource and re-run chef-client --local-mode. Chef will install NGINX via yum on CentOS 7, enable the systemd unit, and start the service — in a single idempotent run.

Moving to a Production Chef Environment

Local mode with Chef Zero is intended for development and learning. A production Chef environment requires a Chef Server to manage multiple nodes, store cookbooks centrally, and handle authentication via SSL certificates. You have two primary options:

• Self-hosted Chef Server: Install and operate a Chef Server on your own infrastructure (on-premises or in a private cloud).
• Chef SaaS / Hosted Chef: Use Progress Chef’s hosted offering, where you create an account, upload cookbooks with knife cookbook upload, and register nodes against the hosted endpoint.

Major public cloud providers, including AWS and Microsoft Azure, also offer marketplace integrations and managed Chef Server options to simplify infrastructure management at scale.

Summary

This tutorial covered the essential steps to get started with Chef configuration management on a single CentOS 7 machine:

1. Install Chef DK and configure the shell environment.
2. Install Git and generate a Chef repository with chef generate app.
3. Write a simple file resource in a recipe’s default.rb.
4. Execute the recipe with chef-client --local-mode and validate the output.
5. Extend the recipe to manage packages and services (NGINX example).

From here, explore attributes, templates, data bags, and roles to build production-grade cookbooks. The Chef documentation is the authoritative reference for all these concepts.

accelerated dePublic cloud platforms such as AWS have changed how many businesses develop applications. Cloud affords development times — and enables some dev teams to release new features and app updates multiple times a day. But none of this would be possible without a vast array of DevOps tools and services.

After an AWS migration, businesses can model their infrastructure as code (IaC), build and test code with managed services and automate deployments using continuous integration (CI) and continuous delivery (CD) orchestration services. Enterprises that haven’t yet embraced cloud, however, have a long wait before they can see the benefits of using AWS DevOps tools. But before IT teams become technically proficient with AWS tools and services, they must make a cultural shift and change the way they think about traditional deployments.

Businesses should devise a strategy to take advantage of the new capabilities that are available after moving to AWS. Businesses can reach improved levels of operational maturity post-AWS migration, but it takes commitment and know-how from all lines of business.

Use CI and CD

CI is useful when merging small changes to code into a central repository. Admins then can run automated builds and unit tests to compile applications and ensure the code works as expected. This process helps to quickly identify bugs and improve software quality.

CD takes CI a step further. The CD process ensures that the code is ready to move to development or staging for further testing. Once all tests have passed, the latest version of the application is deployable to production.

Businesses can implement CI and CD with AWS-native services. AWS CodeCommit works as a secure version-control repository; AWS CodeBuild automatically performs builds when code enters the repository. AWS CodePipeline makes sure committed code is automatically built, tested and deployed into testing or staging environments, which ties together the various CI and CD services.

Background: Why Configuration Management Matters in Modern DevOps

The shift toward customer-centric digital businesses, combined with the adoption of agile and DevOps practices, has accelerated enterprise migration to cloud platforms. Moving legacy IT systems to the cloud offers clear advantages: global development reach, shorter deployment cycles, and faster time to market for new features.

From a quality assurance perspective, this shift places new demands on test environment management. Testers need environments that spin up quickly, match production configurations accurately, and remain consistent across iterations. In traditional software development, configuration management (CM) was largely a manual discipline focused on maintaining the consistency of a platform’s functional and physical attributes. In a cloud-native DevOps context, that manual approach becomes a significant bottleneck.

Modern projects require automated environment provisioning that is both instantaneous and repeatable — ensuring that each new environment mirrors its predecessors exactly. Configuration management is therefore a foundational challenge when building a robust test environment management framework on cloud infrastructure.

Types of Test Environments

Test environments in cloud-based DevOps pipelines generally fall into several categories. According to the World Quality Report 2016, testing typically occurs across the following environment types:

• Permanent, cloud-based environments: Long-lived environments hosted on cloud infrastructure, used for sustained integration or regression testing.
• Temporary, cloud-based environments: On-demand environments that are provisioned for a specific test run and then decommissioned to reduce cost.
• Virtualized test environments: Environments running on virtual machines or containers, enabling rapid cloning and parallel test execution.
• Temporary, non-cloud environments: Short-lived environments built on on-premises infrastructure for isolated or compliance-driven testing scenarios.

Configuration and Environment Management on Cloud: Scope and Challenges

A well-defined configuration management policy is central to determining whether test environments are genuinely ready to operate in the cloud. The scope of CM services for test environments covers three core activities:

1. Defining and implementing configuration management policies
2. Establishing reference configurations for each environment type
3. Developing and maintaining a configuration management plan

Beyond these strategic activities, day-to-day CM operations for test environments typically include:

• Administering the configuration management toolset
• Monitoring and continuously improving CM processes and assets
• Validating and deploying software releases
• Promoting configuration changes across development, testing, staging, and production environments
• Automating configuration deployment and compliance reporting tasks
• Validating and publishing release notes

The primary objective of test environment management is fast setup time combined with on-demand availability. Meeting this objective requires accelerating the deployment pipeline and stabilising environments at each stage. Delays in promoting code from development through testing to staging must be eliminated through automation.

The World Quality Report 2016 identified managing multiple versions of ERP test environments as a persistent challenge, attributing much of the difficulty to the absence of automated CM tooling for cloud-hosted test environments.

Building an Automated Configuration Management Toolset

The foundation of automated CM for test environments is a toolset capable of discovering system state, generating compliance reports, and executing configuration changes consistently across environments. The following step-by-step approach provides a practical implementation path:

1. Identify configuration items (CIs): Catalogue the OS-level items (firewall rules, hostnames, network settings) and application-level items that need to be managed and tracked.
2. Select and install a CM tool: Choose a configuration management engine suited to your stack and team skill set. Common options include Puppet, Chef, Ansible, and Salt. Each uses a different paradigm (agent-based vs. agentless, declarative vs. procedural), so evaluate them against your environment constraints.
3. Integrate supporting tooling: Connect your CM tool to version control (Git), a CI server (Jenkins), and a build tool (Maven or equivalent) to create a fully automated pipeline from code commit to environment deployment.
4. Generate baseline reports: Produce “as-is” configuration reports to document the current state of all managed environments before making changes.
5. Write deployment scripts: Build CM scripts (Puppet manifests, Chef cookbooks, Ansible playbooks, or Salt states) that codify desired environment configurations.
6. Establish an automated deployment workflow: Define the promotion workflow so that tested configurations move automatically from development to test to staging environments with minimal manual intervention.
7. Document procedures: Record deployment procedures, rollback plans, and environment specifications so the process is repeatable by any team member.
8. Release for operational use: Publish the validated CM scripts and workflows for use by development, QA, and operations teams.

Choosing the Right Configuration Management Tool

The four most widely adopted open-source CM tools each have distinct characteristics worth understanding before committing to one:

In practice, many teams combine tools: for example, using Terraform for infrastructure provisioning, Ansible for configuration management, and Jenkins for orchestrating the end-to-end pipeline.

Benefits of Automating Configuration Management

Automating configuration management across test environments delivers measurable improvements to DevOps delivery pipelines:

• Consistency and repeatability: Codified configurations eliminate environment drift, ensuring that every provisioned environment is identical to its predecessors.
• Faster environment provisioning: On-demand spin-up and teardown reduces idle environment costs and unblocks testers waiting for environments.
• Better pipeline control and asset utilisation: Automated management improves visibility into environment state, enabling smarter scheduling and reducing total cost of ownership (TCO).
• Improved productivity: Integrating health checks and smoke tests (shakedowns) into automated build and deployment workflows means teams spend less time diagnosing environment issues and more time testing product functionality.
• Audit and compliance: Automated CM reports provide an auditable record of configuration state at every stage of the pipeline.

Conclusion

As cloud adoption accelerates and DevOps pipelines grow in complexity, manual configuration management can no longer keep pace. Automating CM across test environments — using tools like Puppet, Chef, Ansible, or Salt, integrated with Git, Jenkins, and complementary tooling — enables teams to provision consistent, on-demand environments at the speed the business demands. The result is a more focused development and testing practice with lower operational overhead and higher confidence in release quality.

Background: Why Native Binary Dependencies Are Complicated

If your primary experience is with managed-runtime languages — Java, C#, Ruby — or with Windows development, you may never have had to think deeply about how a compiled binary finds its dependencies at runtime on Linux. On Windows, finding a missing low-level dependency usually means downloading an MSI and moving on. The situation on Linux is meaningfully different, and understanding it is essential for anyone building software with Chef Habitat.

This article explains the fundamentals of ELF binaries, static versus dynamic linking, and how Habitat exploits dynamic linking to deliver genuine, dependency-complete application portability.

What Is an ELF Binary?

ELF stands for Executable and Linkable Format. It is the standard binary format used for executables, shared libraries, and object files on Linux and most Unix-like systems. An ELF file is structured as a set of headers followed by named sections (commonly .text for machine instructions, .data for initialised data, and so on).

One of the most important jobs of an ELF binary is to tell the operating system how to load the program into memory and which external symbols (functions, variables) must be resolved before the program can run. That information lives in dedicated ELF sections and is read by the dynamic linker — typically ld-linux.so — every time the binary is executed.

Compiling vs. Linking: Two Distinct Steps

Developers often use the word “compiling” to mean the whole build process, but there are actually two separate operations:

• Compiling — The compiler reads source code files and translates them into machine-language object files (.o files). Object files on their own cannot be executed.
• Linking — The linker (ld on Linux) takes one or more object files, resolves references to external libraries, and produces a final executable or shared library. If your code calls a function from an external library and that function cannot be found, the linker — not the compiler — reports the error.

Static vs. Dynamic Linking

Static Linking

In static linking, the machine code from every external library is copied directly into the final executable. The result is a single, self-contained binary with no runtime dependency on external shared object files. Static binaries are easy to deploy, but they are larger and must be recompiled and redeployed whenever a dependency is updated (for example, to patch a security vulnerability).

Dynamic Linking

Dynamic linking keeps external code outside the executable. Instead of embedding library code, the linker writes metadata into the ELF binary that names the required shared object files (.so on Linux, .dll on Windows). When the binary is executed, the operating system’s dynamic linker reads that metadata and loads the correct shared libraries into the process at runtime.

The benefits of dynamic linking include:

• Smaller application binaries, because library code is not duplicated.
• The ability to update a shared library across all applications that use it without recompiling any of them.
• Memory efficiency, because the OS can share a single copy of a loaded library between multiple running processes.

The trade-off is that the correct version of every required shared library must be present on the target machine at runtime. This is the classic source of “it works on my machine” deployment failures.

How the Linux Dynamic Linker Finds Shared Libraries

The linker (ld) and the runtime dynamic linker (ld-linux.so) follow a strict, ordered set of rules when searching for shared libraries. Understanding this order is critical for diagnosing dependency errors and for understanding how Habitat controls the process. The following search order is taken directly from the ld man page:

1. Directories specified by -rpath-link options (link time only; not embedded in the binary).
2. Directories specified by -rpath options (embedded in the ELF binary and honoured at runtime).
3. The contents of the LD_RUN_PATH environment variable, if -rpath and -rpath-link were not used (ELF, native linkers only).
4. On SunOS, directories specified by -L options if -rpath was not used.
5. The contents of the LD_LIBRARY_PATH environment variable (native linkers).
6. The DT_RUNPATH or DT_RPATH entries inside a shared library being loaded (DT_RPATH is ignored if DT_RUNPATH is present).
7. The default system directories: normally /lib and /usr/lib.
8. Directories listed in /etc/ld.so.conf (ELF systems with a native linker).

Two entries in this list are especially important for Habitat: -rpath (step 2) and DT_RUNPATH/DT_RPATH (step 6). Both allow a path to be baked directly into an ELF binary so that the runtime linker knows exactly where to look — regardless of what is installed in /usr/lib or what LD_LIBRARY_PATH says.

The Dependency Problem in Traditional Linux Deployments

Consider a common scenario: your application depends on the ZeroMQ library. During development you run apt-get install libzmq-dev and the library lands somewhere under /usr. Your application builds and runs. When you promote to production, you (or your configuration management tool) must ensure that the same library — ideally at the same version — is installed on every production node.

This is fragile for several reasons:

• Different Linux distributions package different versions of the same library.
• Two applications on the same node may require different, incompatible versions of the same library. Most package managers cannot install multiple versions of a library into /usr/lib simultaneously.
• Configuration management tools such as Chef can enforce that a specific version is installed, but they cannot easily manage version conflicts between co-located applications.

How Habitat Solves the Problem with Dynamic Linking

Dependencies Travel with the Application

Habitat packages applications as .hart files. When a Habitat package is installed, Habitat also installs every package listed in the application’s dependency manifest. These packages are placed under Habitat’s own root directory (by default /hab/pkgs/), completely separate from the system’s /usr tree. They do not conflict with system-installed libraries or with libraries belonging to other Habitat-managed applications.

Build-Time and Runtime Paths Are the Same

During the Habitat build process, the linker is configured to embed the paths to Habitat-managed dependencies directly into the resulting ELF binary using RPATH or RUNPATH entries. This means that at runtime, the dynamic linker resolves shared libraries from those same Habitat package directories — not from /usr/lib or whatever happens to be on LD_LIBRARY_PATH.

The practical consequence: the exact binaries linked at build time are the exact binaries loaded at runtime. No separate configuration management layer is needed to enforce this guarantee.

Side-by-Side Versioning

Because each Habitat application’s dependencies live under their own versioned paths within /hab/pkgs/, two applications on the same node can depend on different versions of the same library and run simultaneously without conflict. The RPATH baked into each binary points to its own specific dependency version.

The Habitat Studio: Keeping Builds Clean

A potential weakness in this model is the build step itself. If during a build the linker silently falls through to /usr/lib and picks up a system library that is not listed as a Habitat dependency, the resulting binary will have a runtime dependency that Habitat does not know about and will not install. The package would break on any node that does not happen to have that exact system library version installed.

Habitat prevents this with the Studio: a clean, minimal, isolated build environment. Inside the Studio, system library paths are not available to the linker. The only libraries the linker can find are those explicitly declared as Habitat dependencies in the build plan. If your plan is missing a dependency, the build fails loudly inside the Studio — which is exactly the right behaviour. A build failure during development is far preferable to a mysterious runtime failure in production.

Practical Implications for Plan Authors

Understanding the ELF linker search order and how Habitat manipulates it helps you write better build plans and diagnose build failures faster. Key points to keep in mind:

• Declare all dependencies explicitly. If a library your software needs is not in your plan’s dependency list, the Studio build will fail. Treat that failure as useful signal, not an annoyance.
• Be cautious with build systems that hard-code paths. CMake files, configure scripts, and downloaded pre-built binaries may expect libraries in /usr/lib. Inside the Habitat Studio those paths do not exist, so such build systems require patching or careful configuration.
• Understand -rpath vs LD_LIBRARY_PATH. Relying on LD_LIBRARY_PATH at runtime is fragile because it can be overridden or unset. Habitat favours embedding paths directly in the binary via RPATH/RUNPATH, which is more robust.
• Software that uses non-GCC toolchains adds complexity. Projects that use Clang or non-standard build systems (such as .NET Core) may download pre-compiled binaries or have build scripts that assume standard filesystem layouts. These require additional work to Habitat-ise correctly.

Summary

ELF binaries on Linux carry metadata that tells the dynamic linker exactly where to find shared library dependencies at runtime. By controlling that metadata during the Habitat build process — specifically by embedding Habitat package paths into the binary’s RPATH/RUNPATH — Habitat guarantees that an application always loads the same dependencies it was built against, regardless of what is installed on the host system. The Habitat Studio enforces this at build time by removing access to system library paths entirely. The result is genuine, reproducible application portability: install the .hart package and everything the application needs comes with it.