🥇Introdución a GitOps para OpenShift

Hoxe falaremos dos principios e modelos de GitOps, así como de como se implementan estes modelos na plataforma OpenShift. Hai unha guía interactiva sobre este tema dispoñible по ссылке.

En poucas palabras, GitOps é un conxunto de prácticas para usar solicitudes de extracción de Git para xestionar a infraestrutura e as configuracións das aplicacións. O repositorio de Git en GitOps trátase como unha única fonte de información sobre o estado do sistema, e calquera cambio neste estado é totalmente rastrexable e auditable.

A idea do seguimento de cambios en GitOps non é de ningún xeito nova; este enfoque utilizouse durante moito tempo case de forma universal cando se traballa co código fonte da aplicación. GitOps simplemente implementa funcións similares (recensións, solicitudes de extracción, etiquetas, etc.) na xestión da infraestrutura e da configuración de aplicacións e ofrece beneficios similares aos da xestión do código fonte.

Non hai unha definición académica nin un conxunto de regras aprobados para GitOps, só un conxunto de principios sobre os que se basea esta práctica:

A descrición declarativa do sistema gárdase no repositorio de Git (configuracións, seguimento, etc.).
Os cambios de estado realízanse mediante solicitudes de extracción.
O estado dos sistemas en execución axústase aos datos do repositorio mediante solicitudes push de Git.

Principios de GitOps

As definicións do sistema descríbense como código fonte

A configuración dos sistemas trátase como código polo que se pode almacenar e versionar automaticamente nun repositorio de Git, que serve como fonte única de verdade. Este enfoque facilita a implementación e a recuperación dos cambios nos sistemas.

O estado desexado e a configuración dos sistemas están definidos e versionados en Git

Ao almacenar e versionar o estado desexado dos sistemas en Git, podemos implementar e retrotraer facilmente os cambios en sistemas e aplicacións. Tamén podemos usar os mecanismos de seguridade de Git para controlar a propiedade do código e verificar a súa autenticidade.

Os cambios de configuración pódense aplicar automaticamente mediante solicitudes de extracción

Usando as solicitudes de extracción de Git, podemos controlar facilmente como se aplican os cambios ás configuracións do repositorio. Por exemplo, pódense entregar a outros membros do equipo para a súa revisión ou realizar probas de CI, etc.

E, ao mesmo tempo, non hai necesidade de distribuír poderes de administración á esquerda e á dereita. Para realizar cambios de configuración, os usuarios só necesitan os permisos axeitados no repositorio de Git onde se almacenan esas configuracións.

Solucionando o problema da deriva incontrolada das configuracións

Unha vez que o estado desexado do sistema está almacenado nun repositorio de Git, todo o que temos que facer é atopar un software que garanta que o estado actual do sistema coincide co estado desexado. Se non é o caso, entón este software debería, dependendo da configuración, eliminar a discrepancia por si só ou notificarnos sobre a deriva da configuración.

Modelos GitOps para OpenShift

Reconciliador de recursos no clúster

Segundo este modelo, o clúster ten un controlador que se encarga de comparar os recursos de Kubernetes (ficheiros YAML) no repositorio de Git cos recursos reais do clúster. Se se detectan discrepancias, o controlador envía notificacións e posiblemente tome medidas para corrixir as discrepancias. Este modelo GitOps úsase en Anthos Config Management e Weaveworks Flux.

Reconciliador de recursos externos (Push)

Este modelo pódese considerar como unha variación do anterior, cando temos un ou varios controladores encargados de sincronizar os recursos nos pares “Repositorio Git - clúster Kubernetes”. A diferenza aquí é que cada clúster xestionado non ten necesariamente o seu propio controlador separado. Os pares de clúster Git - k8s adoitan definirse como CRD (definicións de recursos personalizados), que poden describir como o controlador debe realizar a sincronización. Dentro deste modelo, os controladores comparan o repositorio de Git especificado no CRD cos recursos do clúster de Kubernetes, que tamén se especifican no CRD, e realizan as accións adecuadas en función dos resultados da comparación. En particular, este modelo GitOps úsase en ArgoCD.

GitOps na plataforma OpenShift

Administración da infraestrutura de Kubernetes multiclúster

Coa expansión de Kubernetes e a crecente popularidade das estratexias multi-nube e da computación de borde, o número medio de clústeres OpenShift por cliente tamén está aumentando.

Por exemplo, cando se usa a informática de punta, os clústeres dun cliente pódense implantar en centos ou incluso miles. Como resultado, vese obrigado a xestionar varios clústeres OpenShift independentes ou coordinados na nube pública e local.

Neste caso, hai que resolver moitos problemas, en particular:

Controla que os clústeres estean nun estado idéntico (configuracións, seguimento, almacenamento, etc.)
Recrear (ou restaurar) clústeres baseándose nun estado coñecido.
Crear novos clústeres baseados nun estado coñecido.
Realiza cambios en varios clústeres de OpenShift.
Retroceder os cambios en varios clústeres de OpenShift.
Vincular configuracións con modelos a diferentes contornos.

Configuración de aplicacións

Durante o seu ciclo de vida, as aplicacións adoitan pasar por unha cadea de clústeres (dev, stage, etc.) antes de acabar nun clúster de produción. Ademais, debido aos requisitos de dispoñibilidade e escalabilidade, os clientes adoitan implementar aplicacións en varios clústeres locais ou en varias rexións dunha plataforma de nube pública.

Neste caso, hai que resolver as seguintes tarefas:

Garantir o movemento de aplicacións (binarios, configuracións, etc.) entre clusters (dev, stage, etc.).
Introduza cambios nas aplicacións (binarios, configuracións, etc.) en varios clústeres de OpenShift.
Retroceder os cambios das aplicacións a un estado anterior coñecido.

Casos de uso de OpenShift GitOps

1. Aplicando cambios desde o repositorio de Git

Un administrador de clúster pode almacenar configuracións de clúster de OpenShift nun repositorio de Git e aplicalas automaticamente para crear novos clústeres sen esforzo e colocalos nun estado idéntico ao estado coñecido almacenado no repositorio de Git.

2. Sincronización con Secret Manager

O administrador tamén se beneficiará da posibilidade de sincronizar obxectos secretos de OpenShift co software axeitado como Vault para xestionalos mediante ferramentas creadas especialmente para iso.

3. Control de configuracións de deriva

O administrador só estará a favor se o propio OpenShift GitOps identifica e advirte sobre discrepancias entre as configuracións reais e as especificadas no repositorio, para que poidan responder rapidamente á deriva.

4. Notificacións sobre a deriva da configuración

Son útiles no caso de que o administrador quere coñecer rapidamente os casos de deriva da configuración para tomar rapidamente as medidas adecuadas por si mesmo.

5. Sincronización manual de configuracións ao derivar

Permite ao administrador sincronizar o clúster OpenShift co repositorio de Git en caso de desviación da configuración, para devolver rapidamente o clúster a un estado anterior coñecido.

6.Autosincronización das configuracións ao derivar

O administrador tamén pode configurar o clúster OpenShift para que se sincronice automaticamente co repositorio cando se detecte unha deriva, de xeito que a configuración do clúster sempre coincida coas configuracións de Git.

7. Varios clusters - un repositorio

O administrador pode almacenar configuracións de varios clústeres OpenShift diferentes nun repositorio de Git e aplicalas selectivamente segundo sexa necesario.

8. Xerarquía de configuracións de clúster (herdanza)

O administrador pode establecer unha xerarquía de configuracións de clúster no repositorio (etapa, produto, carteira de aplicacións, etc. con herdanza). Noutras palabras, pode determinar se as configuracións deben aplicarse a un ou máis clústeres.

Por exemplo, se un administrador establece a xerarquía "Clústeres de produción (produción) → Clústeres do sistema X → Clústeres de produción do sistema X" no repositorio de Git, aplícase unha combinación das seguintes configuracións aos clústeres de produción do sistema X:

Configuracións comúns a todos os clústeres de produción.
Configuración para o clúster System X.
Configuracións para o clúster de produción do sistema X.

9. Modelos e substitucións de configuración

O administrador pode anular un conxunto de configuracións herdadas e os seus valores, por exemplo, para axustar a configuración de clústeres específicos aos que se aplicarán.

10. Incluír e excluír selectivamente para configuracións, configuracións de aplicacións

O administrador pode establecer as condicións para a aplicación ou a non aplicación de determinadas configuracións a clusters con determinadas características.

11. Soporte de modelos

Os desenvolvedores beneficiaranse da posibilidade de escoller como se definirán os recursos da aplicación (Helm Chart, puro yaml de Kubernetes, etc.) para poder utilizar o formato máis axeitado para cada aplicación específica.

Ferramentas GitOps na plataforma OpenShift

ArgoCD

ArgoCD implementa o modelo de conciliación de recursos externos e ofrece unha IU centralizada para orquestrar relacións un a moitos entre clústeres e repositorios Git. As desvantaxes deste programa inclúen a imposibilidade de xestionar aplicacións cando ArgoCD non funciona.

Sitio web oficial

Fluxo

Flux implementa un modelo de conciliación de recursos no clúster e, como resultado, non hai unha xestión centralizada do repositorio de definicións, o que é un punto débil. Por outra banda, precisamente pola falta de centralización, a capacidade de xestionar aplicacións mantense aínda que falle un clúster.

Sitio web oficial

Instalación de ArgoCD en OpenShift

ArgoCD ofrece unha excelente interface de liña de comandos e unha consola web, polo que non trataremos aquí Flux e outras alternativas.

Para implementar ArgoCD na plataforma OpenShift 4, siga estes pasos como administrador do clúster:

Implantación de compoñentes de ArgoCD na plataforma OpenShift

# Create a new namespace for ArgoCD components
oc create namespace argocd
# Apply the ArgoCD Install Manifest
oc -n argocd apply -f https://raw.githubusercontent.com/argoproj/argo-cd/v1.2.2/manifests/install.yaml
# Get the ArgoCD Server password
ARGOCD_SERVER_PASSWORD=$(oc -n argocd get pod -l "app.kubernetes.io/name=argocd-server" -o jsonpath='{.items[*].metadata.name}')

Mellora do servidor ArgoCD para que poida ser visto por OpenShift Route

# Patch ArgoCD Server so no TLS is configured on the server (--insecure)
PATCH='{"spec":{"template":{"spec":{"$setElementOrder/containers":[{"name":"argocd-server"}],"containers":[{"command":["argocd-server","--insecure","--staticassets","/shared/app"],"name":"argocd-server"}]}}}}'
oc -n argocd patch deployment argocd-server -p $PATCH
# Expose the ArgoCD Server using an Edge OpenShift Route so TLS is used for incoming connections
oc -n argocd create route edge argocd-server --service=argocd-server --port=http --insecure-policy=Redirect

Implementación da ferramenta ArgoCD Cli

# Download the argocd binary, place it under /usr/local/bin and give it execution permissions
curl -L https://github.com/argoproj/argo-cd/releases/download/v1.2.2/argocd-linux-amd64 -o /usr/local/bin/argocd
chmod +x /usr/local/bin/argocd

Cambiando o contrasinal de administrador do servidor ArgoCD

# Get ArgoCD Server Route Hostname
ARGOCD_ROUTE=$(oc -n argocd get route argocd-server -o jsonpath='{.spec.host}')
# Login with the current admin password
argocd --insecure --grpc-web login ${ARGOCD_ROUTE}:443 --username admin --password ${ARGOCD_SERVER_PASSWORD}
# Update admin's password
argocd --insecure --grpc-web --server ${ARGOCD_ROUTE}:443 account update-password --current-password ${ARGOCD_SERVER_PASSWORD} --new-password

Despois de completar estes pasos, pode traballar con ArgoCD Server a través da consola web ArgoCD WebUI ou da ferramenta de liña de comandos ArgoCD Cli.
https://blog.openshift.com/is-it-too-late-to-integrate-gitops/

GitOps - Nunca é demasiado tarde

"O tren saíu" - isto é o que din sobre unha situación na que se perde a oportunidade de facer algo. No caso de OpenShift, o desexo de comezar a usar inmediatamente esta nova plataforma xenial adoita crear exactamente esta situación coa xestión e mantemento de rutas, despregamentos e outros obxectos de OpenShift. Pero a oportunidade sempre se perde por completo?

Continuando a serie de artigos sobre GitOps, hoxe mostrarémosche como transformar unha aplicación artesanal e os seus recursos nun proceso no que todo é xestionado por ferramentas GitOps. Para iso, primeiro implementaremos manualmente a aplicación httpd. A seguinte captura de pantalla mostra como creamos un espazo de nomes, unha implementación e un servizo, e despois expomos este servizo para crear unha ruta.

oc create -f https://raw.githubusercontent.com/openshift/federation-dev/master/labs/lab-4-assets/namespace.yaml
oc create -f https://raw.githubusercontent.com/openshift/federation-dev/master/labs/lab-4-assets/deployment.yaml
oc create -f https://raw.githubusercontent.com/openshift/federation-dev/master/labs/lab-4-assets/service.yaml
oc expose svc/httpd -n simple-app

Así que temos unha aplicación artesanal. Agora ten que ser transferido baixo a xestión de GitOps sen perda de dispoñibilidade. En resumo, fai isto:

Crea un repositorio Git para o código.
Exportamos os nosos obxectos actuais e subímolos ao repositorio de Git.
Selección e implantación de ferramentas GitOps.
Engadimos o noso repositorio a este conxunto de ferramentas.
Definimos a aplicación no noso conxunto de ferramentas GitOps.
Realizamos unha proba da aplicación usando o kit de ferramentas GitOps.
Sincronizamos obxectos usando o kit de ferramentas GitOps.
Activa a poda e a sincronización automática de obxectos.

Como se mencionou no anterior Artigo, en GitOps hai unha e só unha fonte de información sobre todos os obxectos do clúster(s) de Kubernetes: o repositorio de Git. A continuación, partimos da premisa de que a súa organización xa usa un repositorio Git. Pode ser público ou privado, pero debe ser accesible para os clústeres de Kubernetes. Este pode ser o mesmo repositorio que para o código da aplicación ou un repositorio separado creado especificamente para implementacións. Recoméndase ter permisos estritos no repositorio xa que alí se almacenarán segredos, rutas e outras cousas sensibles á seguridade.

No noso exemplo, crearemos un novo repositorio público en GitHub. Podes chamalo como queiras, usamos o nome blogpost.

Se os ficheiros de obxecto YAML non se almacenaron localmente ou en Git, terás que usar os binarios oc ou kubectl. Na seguinte captura de pantalla estamos solicitando YAML para o noso espazo de nomes, implantación, servizo e ruta. Antes disto, clonamos o repositorio recén creado e o cd nel.

oc get namespace simple-app -o yaml --export > namespace.yaml
oc get deployment httpd -o yaml -n simple-app --export > deployment.yaml
oc get service httpd -o yaml -n simple-app --export > service.yaml
oc get route httpd -o yaml -n simple-app --export > route.yaml

Agora imos editar o ficheiro deployment.yaml para eliminar o campo que Argo CD non pode sincronizar.

sed -i '/sgeneration: .*/d' deployment.yaml

Ademais, hai que modificar o percorrido. Primeiro estableceremos unha variable multiliña e despois substituiremos ingress: null co contido desa variable.

export ROUTE="  ingress:                                                            
    - conditions:
        - status: 'True'
          type: Admitted"

sed -i "s/  ingress: null/$ROUTE/g" route.yaml

Entón, ordenamos os ficheiros, só queda gardalos no repositorio de Git. Despois diso, este repositorio convértese na única fonte de información, e calquera cambio manual aos obxectos debería estar estrictamente prohibido.

git commit -am ‘initial commit of objects’
git push origin master

Ademais, partimos do feito de que xa implantou ArgoCD (como facelo - ver anterior publicación). Polo tanto, engadiremos ao CD de Argo o repositorio que creamos, que contén o código da aplicación do noso exemplo. Só asegúrese de especificar o repositorio exacto que creou anteriormente.

argocd repo add https://github.com/cooktheryan/blogpost

Agora imos crear a aplicación. A aplicación establece valores para que o conxunto de ferramentas GitOps entenda que repositorio e camiños usar, que OpenShift é necesario para xestionar obxectos, que rama específica do repositorio é necesaria e se os recursos deben sincronizarse automaticamente.

argocd app create --project default 
--name simple-app --repo https://github.com/cooktheryan/blogpost.git 
--path . --dest-server https://kubernetes.default.svc 
--dest-namespace simple-app --revision master --sync-policy none

Unha vez que se especifica unha aplicación no CD de Argo, o conxunto de ferramentas comeza a comprobar os obxectos xa implantados coas definicións do repositorio. No noso exemplo, a sincronización automática e a limpeza están desactivadas, polo que os elementos aínda non cambian. Teña en conta que na interface de Argo CD a nosa aplicación terá o estado "Fóra de sincronización" porque ArgoCD non ofrece ningunha etiqueta.
É por iso que cando comecemos a sincronización un pouco máis tarde, os obxectos non se volverán desplegar.

Agora imos facer unha proba para asegurarnos de que non hai erros nos nosos ficheiros.

argocd app sync simple-app --dry-run

Se non hai erros, pode continuar coa sincronización.

argocd app sync simple-app

Despois de executar o comando argocd get na nosa aplicación, deberíamos ver que o estado da aplicación cambiou a San ou Sincronizado. Isto significará que todos os recursos do repositorio de Git agora corresponden a aqueles recursos que xa foron despregados.

argocd app get simple-app
Name:               simple-app
Project:            default
Server:             https://kubernetes.default.svc
Namespace:          simple-app
URL:                https://argocd-server-route-argocd.apps.example.com/applications/simple-app
Repo:               https://github.com/cooktheryan/blogpost.git
Target:             master
Path:               .
Sync Policy:        <none>
Sync Status:        Synced to master (60e1678)
Health Status:      Healthy
...

Agora podes activar a sincronización e a limpeza automáticas para asegurarte de que non se crea nada manualmente e de que cada vez que se cree ou actualice un obxecto no repositorio, se produza unha implantación.

argocd app set simple-app --sync-policy automated --auto-prune

Entón, levamos con éxito unha aplicación baixo o control de GitOps que inicialmente non usaba GitOps de ningún xeito.

Fonte: www.habr.com

Introdución a GitOps para OpenShift