A standard way of managing configurations for multiple environments (and clouds)

A standard way of managing configurations for multiple environments (and clouds)

  • September 14, 2019
Table of Contents

A standard way of managing configurations for multiple environments (and clouds)

This article intended to share ideas and solutions to address some challenges related to Configuration Management, especially in the cloud environment. Hope you find this read helpful. The approach described in this article was conceptualized a few years back, then implemented and used across many, many projects to build configuration management components for production-grade systems and applications.

This problem is quite common and we have seen it over the years not only in cloud-based deployments and environments but also in the local type of deployments, similar to “3 blades in the rack next room”. This problem is applicable to any deployment with more than 1 environment in the picture, like DEV, QA, STG, PROD and so on. And the problem is, as you probably have guessed, the configuration data and its management.

Wiki talks about Configuration Management(CM) in great length – CM planning and management, controls, status, so on and so forth, but I’m as architect and DevOps engineer always about the details (well, that’s where you-know-who is..) and about how to get this done in fastest and most efficient way.

Source: itnext.io

Share :
comments powered by Disqus

Related Posts

Announcing etcd 3.4

Announcing etcd 3.4

In particular, etcd experienced performance issues with a large number of concurrent read transactions even when there is no write (e.g. “read-only range request … took too long to execute”). Previously, the storage backend commit operation on pending writes blocks incoming read transactions, even when there was no pending write. Now, the commit does not block reads which improve long-running read transaction performance.

Read More
YuniKorn: a universal resource scheduler

YuniKorn: a universal resource scheduler

We are super excited today to announce the open-sourcing of one of the exciting new projects we’ve been working behind the scenes at the intersection of big-data and computation platforms – YuniKorn! Yunikorn is a new standalone universal resource-scheduler responsible for allocating/managing resources for big-data workloads including batch jobs and long-running services. YuniKorn is a light-weight, universal resource scheduler for container orchestrator systems.

Read More
How to detect Kubernetes vulnerability CVE-2019-11246 using Falco.

How to detect Kubernetes vulnerability CVE-2019-11246 using Falco.

A recent CNCF-sponsored Kubernetes security audit uncovered CVE-2019-11246, a high-severity vulnerability affecting the command-line kubectl tool. If exploited, it could lead to a directory traversal, allowing a malicious container to replace or create files on a user’s workstation. This vulnerability stemmed from an incomplete fix of a previously disclosed vulnerability (CVE-2019-1002101).

Read More