Red Hat SummitGitOps is an automated approach to system and infrastructure administration in which the capabilities of continuous integration/continuous deployment (CI/CD), and Git-based source code control management are combined to create and subsequently manage enterprise systems quickly and accurately.
Under GitOps, the infrastructure and application state are fully represented by the contents of a Git repository. Thus, any changes to the Git repository are reflected in the corresponding state of the associated infrastructure and applications through automation.
Taking a GitOps approach allows enterprise architects to express a fine degree of description in their architectural designs. For example, instead of just saying, "we'll use a relational database here" and then leaving it up to a DBA to figure things out, an architect can write a detailed specification using a conventional format such as YAML that describes the type of relational database to use along with configuration settings for that database. In addition, the architect can specify the system requirements of the machines that the database will run on, right down to the number of CPUs and maximum utilization thresholds.
The GitOps methodology is both powerful and efficient, but it's no magic bullet. You can't go off willy-nilly and start checking things into a Git repository and hope that it all works out for the best. Some basic guidelines are useful. Thus we offer the following three rules to help make adopting GitOps an easier undertaking. The three rules are:
- Accept that the world is dynamic
- Incorporate declarative definition into your architectural designs
- Embrace automation
Let's take a look at the details of each.
Accept that the world is dynamic
In the old days of manual deployment, enterprise architectures changed slowly. It could take days, if not weeks or months, for a new network topology to make its way from an architect's diagram into the operational fabric of a company's IT infrastructure. Today, when GitOps and CI/CD are in use, it's a matter of hours.
[ Want to dive in deeper? Read What is GitOps? ]
Accommodating fast and continuous change is becoming a typical characteristic of modern enterprise architectures. Thus, architectural designs need to reflect not only the dynamic nature of today's digital infrastructure but the mechanisms by which dynamic change will be implemented. This means incorporating GitOps and CI/CD artifacts, processes, and tooling into the overall architectural design. These items need to be described clearly, as is typical for computing, databases, message brokers, network resources, and application dependencies. Everything required to get an architecture up and running in a dynamic, GitOps—CI/CD environment needs to be known.
The long and the short of it is that a useful design sensibility for enterprise architects intending to adopt GitOps into their work is to understand enterprise systems that are always in motion at various levels and that the architecture needs to describe the many aspects of continuous change accordingly. It's the difference between taking a photograph and making a motion picture. It's a different way of thinking for many but rewarding in the long run for enterprise architects attempting to incorporate GitOps into their designs.
Incorporate declarative definitions into your architectural designs
Designs that are intended to describe the GitOps and CI/CD aspects of your architecture are best done declaratively. In a declarative definition, you specify what you want, not how you want it done. Take a look at the example shown below. It's a snippet of HTML code:
<!DOCTYPE html>
<html>
<body>
<h1>The 3 Stooges</h1>
<ul>
<li>Moe</li>
<li>Larry</li>
<li>Curly</li>
</ul>
</body>
</html>Listing 1: HTML is essentially a declarative format.
The HTML code in Listing 1 is declarative. It's telling the browser that it wants a web page that displays a titled list of the Three Stooges. It is not telling the browser how to render the page. It's just telling the browser what it wants displayed. The same is true of the code in Listing 2, which is an example of a manifest file that defines a Kubernetes network policy.
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: access-nginx
spec:
podSelector:
matchLabels:
app: nginx
ingress:
- from:
- podSelector:
matchLabels:
access: "true"Listing 2: Kubernetes uses a declarative format to define network policies.
Notice that Listing 2 describes details about what the network policy is. It does not tell Kubernetes how to implement that network policy. Implementation is Kubernetes's business.
It is important to master declarative formats in your architectural designs because many GitOps and CI/CD tasks are executed according to declarative definitions. For example, Listing 3 shows a GitHub Action that sends a notification to a Slack channel when a team member opens an issue in GitHub.
name: Post Slack Issues
on:
issues:
types: [opened]
jobs:
post_slack_message:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
- uses: rtCamp/action-slack-notify@v2.0.0
env:
SLACK_WEBHOOK: ${{ secrets.SLACK_WEBHOOK }}
SLACK_USERNAME: Cool Dude
SLACK_CHANNEL: gh-issuesListing 3: GitHub Actions use YAML to define a process declaratively.
Again, notice, as in the other examples, that there is no programming code in this listing. Rather the code declares the resources to use to fulfill a particular objective and when to use them.
The relevance of declarative definition to the GitOps way of doing things is that the Git repository is the single source of truth for all activity in the software development lifecycle—at the architectural level, design time, and runtime. Furthermore, many aspects of the digital infrastructure will be described in declarative documents stored in the source code repository. Thus, expressing the specifics of an architectural design meaningfully in a declarative format is an essential skill for modern enterprise architects that want to integrate the principles of GitOps into their design thinking.
Embrace automation
A digital infrastructure without automation ain't. Automation is at the very foundation of the software development cycle in today's world of enterprise architecture in general and GitOps in particular. While it's true that most enterprise architects won't be creating the actual automation code that's used by a particular architecture, having an awareness of the nuances that are part of creating an automated architecture is nonetheless important.
The analogy is this: Professional conductors of a world-class symphony orchestra won't be playing an instrument during a performance of Beethoven's 5th, but you can rest assured they've sat in an instrumentalist's chair at some point in their career. They understand the nuance of the undertaking. And, everybody—conductor or instrumentalist—is reading from the same score. That score is the specification for the music that will make its way into the listener's ears.
The same is true in enterprise architecture under GitOps. Code is the score that the GitOps automation tooling uses to get an application into the hands of a company's users. Without the code, automation is meaningless. Without automation, the application will never see the light of day. In short, embrace automation.
Putting it all together
GitOps offers many benefits to enterprise architects. They can have a finer degree of specificity in their designs. And, with greater specificity comes more control over the quality of the systems that make their way into production. But, as mentioned previously, GitOps is no magic bullet. You need to have mastery of the methodology to get the results you want. Hopefully, these three rules for applying the principles of enterprise architecture will help you on your journey to incorporate GitOps into the fabric of your enterprise architecture.
저자 소개
Bob Reselman is a nationally known software developer, system architect, industry analyst, and technical writer/journalist. Over a career that spans 30 years, Bob has worked for companies such as Gateway, Cap Gemini, The Los Angeles Weekly, Edmunds.com and the Academy of Recording Arts and Sciences, to name a few. He has held roles with significant responsibility, including but not limited to, Platform Architect (Consumer) at Gateway, Principal Consultant with Cap Gemini and CTO at the international trade finance company, ItFex.
채널별 검색
오토메이션
기술, 팀, 인프라를 위한 IT 자동화 최신 동향
인공지능
고객이 어디서나 AI 워크로드를 실행할 수 있도록 지원하는 플랫폼 업데이트
오픈 하이브리드 클라우드
하이브리드 클라우드로 더욱 유연한 미래를 구축하는 방법을 알아보세요
보안
환경과 기술 전반에 걸쳐 리스크를 감소하는 방법에 대한 최신 정보
엣지 컴퓨팅
엣지에서의 운영을 단순화하는 플랫폼 업데이트
인프라
세계적으로 인정받은 기업용 Linux 플랫폼에 대한 최신 정보
애플리케이션
복잡한 애플리케이션에 대한 솔루션 더 보기
오리지널 쇼
엔터프라이즈 기술 분야의 제작자와 리더가 전하는 흥미로운 스토리
제품
- Red Hat Enterprise Linux
- Red Hat OpenShift Enterprise
- Red Hat Ansible Automation Platform
- 클라우드 서비스
- 모든 제품 보기
툴
체험, 구매 & 영업
커뮤니케이션
Red Hat 소개
Red Hat은 Linux, 클라우드, 컨테이너, 쿠버네티스 등을 포함한 글로벌 엔터프라이즈 오픈소스 솔루션 공급업체입니다. Red Hat은 코어 데이터센터에서 네트워크 엣지에 이르기까지 다양한 플랫폼과 환경에서 기업의 업무 편의성을 높여 주는 강화된 기능의 솔루션을 제공합니다.