Please enable JavaScript.

Coggle requires JavaScript to display documents.

Openshift, IMPORTANTE: para converter um comando normal em um yaml file,…

- - - - 5) Creating containers and pods: é possível criar usando o comando run via kubectl ou oc. Ele possui uma sintaxe de forma: oc run RESOURCE/NAME --image IMAGE [options]. Exempo: o comando a seguir cria uma aplicação/container em um pod chamado web-server que usa a imagem registry.access.redhat.com/ubi8/httpd-24: kubectl run web-server --image registry.access.redhat.com/ubi8/httpd-24. O comando run vai criar containers em pods que estão no current selected project, a não ser que vc cite um local específico citando seu namespace com a option -n
        
        5.2) Options para run:
        
        --command: essa option faz vc executar comandos dentro do container que vc acabou de criar. Cada comando seguido dessa option tem que ser feito por um double dash (--)
        
        -it: use essa option antes do pod name para iniciar uma interactive session/command prompt com o pod.
        
        --restart: determina como o cluster vai responder qndo vc sair do pod. Cite como argumento 'Always', 'OnFailure', 'Never'. Naturalmente, essa configuração está set para always.
        
        --rm: usar essa option antes de --image vai apagar o pod logo após vc sair dele.
        
        --env: especifica uma environment variable, caso necessário
        
        6) Execute commands in runnning containers: use o comando exec junto do kubectl ou oc. O comando segue a sintaxe: oc exec RESOURCE/NAME -- COMMAND [args...] [options]. Exemplo: o comando a seguir executa o comando date no pod my-app: oc exec my-app -- date. Para pods com múltiplos containers, especifique-o com a option -c logo após o nome do pod. Para entrar dentro do pod, use o comando oc rsh
        
        7) Container images: (para signficado, see 1.3). Imagens possuem vários componentes, como o nome, id e tag. A diferença entre eles é que o nome identifica de qual repository (espécie de banco de dados para imagens) a imagem veio; o id identifica a imagem especificamente, como se fosse cpf; e a tag é abenas um label para identificá-la com mais facilidade, no qual pode ser um nome qlqr como 'buceta10'. Agora, o código das imagens são feitos de layers (são instruções, feitas linha por linha, de como construir, do que será feito e o que terá o conteiner. Quanto mais linhas/instruções, mais pesado será a imagem) e metadata (apenas human-readable instructions feitas para vc ou outra pessoa ler e não altera em nada o resultado final. É como se fosse um  )
        
        7.1) base images: cada image é feita a partir de uma base image, tbm chamadas de UBI (universal base images). A red hat é uma das provedoras dessas UBIs e possui 4 variantes:
        
        standard: This image is the primary UBI, which includes DNF, systemd, and utilities such as gzip and tar;
        
        Init: This image simplifies running multiple applications within a single container by managing them with systemd;
        
        minimal: This image is smaller than the init image and provides nice-to-have features. This image uses the microdnf minimal package manager instead of the full-sized version of DNF;
        
        micro: This image is the smallest available UBI, and includes only the minimum packages. For example, this image does not include a package manager.
        
        7.2) Image management: é possível fazer isso via o comando oc image ou utilizando a poderosa tool e comando skopeo, porém, é necessário instalá-lla usando dnf. O skopeo provides commands to help you to manage and inspect container images and container image registries. Grande parte dos comandos skopeo tem a sintaxe comando -options transport_name://image_name. De forma que o transport é o método de transferência de imagem (docker ou dir.). Alguns subcomandos úteis para o skopeo são:
        
        inspect: view low-level info for a image, como env variables e tags, com a option --config para ver mais detalhado;
        
        copy: copiar imagem de um lugar ou repository para outro lugar;
        
        delete: apaga uma imagem de um repositório;
        
        sync: sincronizar uma ou mais imagens de um lugar para outro. Uma alternativa para o copy, pois permite copiar várias imagens de uma source para um destination.
        
        7.2.1) oc image: como alternativa ao skopeo, o comando natural do opensift oc image faz o mesmo que ele. Alguns subcomandos importantes são:
        
        info: inspects and retrieves info about a image;
        
        append: add layers to an image and pushes that image to a registry;
        
        extract: extrai ou copia files de um disco local. Através desse comando, é possível acessar os contents de uma imagem without first running it as a container;
        
        mirror: copy or 'mirror' images de um repositório à outro, como copiar de um respositório privado para um público.
        
        1 more item...
  - - - 1.3) Containers can be split into two concepts: container images and container instances. Este, são criados a partir de images e são um set of running processes isolados por namespaces, e aquele é um conjunto de dados/códigos que servem como uma 'receita de bolo' para a criação do conteiner.
- - - - 1.1) The smallest unit manageable no openshift são os containers. Já em foco nos kubernetes, the smallest unit manageable são os pods, que consistem em um ou mais containers que compartilham de um unico storage space e IP. Além disso, fatures naturais do openshift, como o build e deployconfig são pods.
      - 1.2) structure of resources: a maioria dos recursos do kubernetes tem como base o object spec e o object status. Aquele descreve o intended state do recurso e este descreve o estado atual.
      - xviii) replicaset: Ensure that a specified number of pod replicas are running at any given time
        xxi) buildconfig (bc): define um processo para se executar no projeto openshift. Ex: o S2I usa o buildconfig pra construir uma imagem from an app source code a partir de um git repository.
        xxii) DeploymentConfig (dc): o deployment resource funciona como uma versão melhorada do deploymentconfig, porém, ele ainda é usado.
        xxiii) Ingress: ingress is a Kubernetes resource that provides some of the same features as routes (which are an RHOCP resource). Para criar um, use oc create ingressingress_name
        xxiv) kustomize: é uma ferramenta do kubernetes que serve para configurar e manage manifest files
    - - 2.1) Creating secrets: use o comando (oc / kubectl) create secret generic secret_name
        --from-literal insira_oqueé_o_segredo=insira_qual_o_segredo --from-literal insira_oqueé_o_segredo=insira_qual_o_segredo**.
        
        depois de criar o secret ou configmap, é necessário assign/expose ele ao pod que vc quer. Para isso, primeiro crie o secret/configmap/adiconar o volume no project em que o pod está. Depois, qndo no project que vc quer, escreva: oc set volume/env deployment/deployment_name (se for environment variable, escreva apenas --from secret/configmap/nome) --add --type secret/configmap --secret/configmap-name nome_do_secret/configmap --mount-path /diretório_para_store_secret/configmap
      - 2.2) Creating configmaps: use o comando (oc / kubectl) create configmap map_name
        --from-literal/file key1=config1(no caso de files, coloque o absolute path)
        --from-literal key2=config2
      - 3) PV e PVC: olhe a sessão iix. Existem vários tipos de persistent volumes, incluindo configmaps. Os mais comuns são:
        
        3.1) emptyDir: providencia um diretório vazio por pod para poder store information que, otherwise, seria temporária.
        
        3.1.2) hostPath: mount um file or directory do host node pro seu próprio pod. Para isso, os pods tem que ser privileged.
        
        3.1.3) iSCSI: 'internet small computer system interface' (iSCSI) é um método que providencia storage em 'blocos', de modo que eles não possuem um file system e são mais isolados. Como ele é baseado em IP, o workloads do kubernetes conseguem consumir esses persistent storage.
        
        3.1.4) local: local PVs conseguem acessar local storage devices, como disco e partitions. Local volumes dependem da disponibilidade de outros nodes, o que pode não ser suitable pra todas as aplicações.
        
        3.1.5) NFS: um network file system pode ser acessado de vários pods ao mesmo tempo e, portanto, tem shared data entre pods. Ele ś mais usado pois consegue share data safely .
        
        como o NFS é o único que consegue compartilhar entre pods, ele é o único que tem capacidade de dar permissões read/write pros pods. As permissões funcionam da seguinte forma:
        
        RWO (read/write only: apenas um node consegue read/write. Todos os tipos de PV tem isso);
        
        ROX (read only many: many nodes conseguem permissão apenas para read);
        
        RWX (read/write many: many nodes conseguem permissão para read e write).
        
        3.2) Filesystem e Block: existem dois tipos de PVs, filesystem (default) e block. Este são block volumes que não tem um file system próprio e, por isso, têm benefícios de performance para aplicações que ocupam espaço do disco local. Cria-se um PV com esse tipo ao especificar volumeMode: Block no comando de criação de PV.
        
        3.3) PVCs: um pvc é apenas a request de uma aplicação para claim storage. Um pvc específica algumas storage characteristics. Assim, múltiplos pods conseguem conectar ao mesmo pvc, dado que eles precisem das mesmas características citadas no pvc.
        
        3.1) create a pvc e pv: para criar um recurso pvc e adicioná-lo a uma aplicação, basta usar o comando oc set volumes (introduzido na parte de configmaps). se liga no exemplo de command line:
        
        oc set volumes deployment/nome \
        
        -nome do deployment que precisa de pvc \
        
        --add true/false (true adiciona volumes pros containers) \
        
        --name escreva nome do pv \
        
        --type tipo de PVs \
        
        --claim-mode rwo/rox/rwx \
        
        --claim-size size em bytes na notação SI \
        
        --mount-path absolute path para o mount \
        
        --claim-name nome do pvc
        p.s. para um pvc automaticamente se ligar a um pv, esse pv precisa fit as características do pvc, como o storage.
    - - 4.1) High Availability ou HA é um kubernetes feature e método de evitar que aplicações estejam unavailable, de modo que ela evita acontecimentos como memory leaks, networking issues e etc. Importante dizer que isso não é um security measure, mas sim, um modo de evitar worst case scenarios. HA usa técnicas para improve reliability, como restarting, probing, horizontal scaling (When the application load changes, the cluster can scale the number of replicas to match the load.)
        
        4.2) Health Probes: têm o papel de monitorar, a todo tempo, uma aplicação para determinar seu status. A constante análise dos probes fazem com que o cluster: automaticamente reinicie failing pods; faça load balancing; determine quando e pq o pod está falhando, etc. Há vários tipos de probes:
        
        Readiness Probes: determina se uma aplicação está pronta para receber requests. In the event of the probing result turning out negative, então o kubernetes remove o IP daquele pod/app para não receber tráfego. Um readiness probe, geramente, detecta problemas que são temporários, como falta de conexão, tempo de loading das files no cache está devagar, etc.
        
        Liveness Probes: este está agindo enquanto a aplicação está online. Esse probe determina se o app está em um estado saudável. Se esse probe falhar várias vezes, então o kubernetes vai reiniciar a aplicação;
        
        Startup Probes: esse determina quando o startup de uma aplicação foi completado. Diferentemente do readiness probe, esse só está ativo durante o tempo de iniciação e é geralmente usado para aplicações com um long start time.
        Há duas variáveis importantes quando se fala de probes: a failure threshold (define quantas falhas o probe pode ter até que o processo todo de probing falhe) e period seconds (o quão often, em segundos, o probe vai run). Para criar (ou modificar) um probe, use o comando oc set probe (exclusivo do openshift), de modo que o comando seja escrito:
        oc set probe deployment/nome \
        --readiness/liveness/startup \
        --failure-threshold valor \
        --period-seconds valor \
        --get-url link (no caso de ser um teste do tipo HTTP GET)
        
        4.2.1) Types of probe testing:
        
        HTTP GET: Toda vez que um probe é ativado, o cluster manda um request pro endpoint HTTP específicado. A request só é um success se a response do endpoint for um código que varia de 200 - 399.
        
        Container command: toda vez que um probe é ativado, o cluster run um comando especificado e responde com um código = 0 caso o teste tenha sucedido.
        
        TCP socket: toda vez que o probe é ativado, o cluster tenta abrir um socket (?) no container. Se der certo, the connection is established.
        
        5) Operators: existem diversos tipos de recursos em que cada um ultiliza workloads de maneiras diferentes. Por exemplo, jobs e cronjobs ultilizam workloads temporariamente, mas deployments e stateful sets os ultilizam permanentemente. De modo que estes ultilizam diferentes quantidades de workloads, como por ex, um deploy de front-end ultiliza menos workload do que um deploy de banco de dados. Assim, operators servem para manage e deploy essa quantidade de workloads, automatizando esse processo. Além disso, operators ultilizam Custom Resources (CRs), que contêm a info necessária da aplicação para o operator realizar sua função, como por ex, o nome da app, sizing requirements e etc. Com isso, operators funcionam rastreando o cluster por CRs e, a partir disso, realizando o deploy do workload e criando os recursos necessários para fazê-la funcionar. Como por exemplo, ao criar um banco de dados, o operator responsável por DBs irá criar um stateful set e um PV para prover o banco de dados que está prescrito no CR. Assim, a criação de um CR é basicamente todas as necessidades da aplicação em um lugar só, e o operator monta tudo.
        
        5.1) Deploying operators: existem vários tipos de operators com diferentes funcionalidades.
        
        Cluster operators: providenciam serviços específicos do openshift, como algumas funcionalidades do web console e a autenticação OAuth e vêm com a instalação do openshift;
        
        Add-On operators: são introduzidos, atualizados e managed a partir do Operator Lifecycle Manager (OLM) e são instalados e atualizados através do OperatorHub.
        
        O responsável por manage aqulele tipo de operators é o Cluster Version Operator (CVO). Além disso, o CVO é o responsável por monitorar os operators no sistema. Assim, use o comando oc get clusteroperator para analisá-los.
        O OLM ultiliza diversos resource types para cumprir sua função. Entre esses resources estão os mais importantes: Catalog Source (referencia um operator repository) e Package Manifest (cria um manifest para cada operator contendo a info necessária para sua instalação).
        
        5.2) Installing operators: siga esses passos:
        
        Locate the operator to install.
        
        Review the operator and its documentation for installation options and requirements.
        
        Decide the update channel to use.
        
        Decide the installation mode. For most operators, you should make them available to all namespaces.
        
        Decide to deploy the operator workload to an existing namespace or to a new namespace.
        
        Decide whether the Operator Lifecycle Manager (OLM) applies updates automatically, or requires an administrator to approve updates.
        
        Create an operator group if needed for the installation mode.
        
        Create a namespace for the operator workload if needed.
        
        Create the operator subscription.
        
        Review and test the operator installation.
        
        5.2.1) Examine available operators:
        
        ultilize o comando oc get catalogsource -n openshift-marketplace para entrar no marketplace namespace e ver os operators disponíveis;
        
        O OLM cria um package manifest para cada operator na lista de referências. O comando oc get packagemanifests mostra quais estão available para instalação.
        
        Após analisar qual operator quer instalar, use o comando oc describe packagemanifest nome_operator -n openshift-marketplace para analisar sua manifest file. NOTA: essa file é muito importante analisar. Leia ela toda e tente compreender
        
        use o comando oc get csv -A para list os installed operators. Esse commando mostra o cluster service version em todos os namespaces. Mostrar os operators é apenas uma consequência.
        
        Use the command oc get clusteroperatorto list the cluster operators and their status.
- - - - 6) Image Streams: assegura a reprodutividade e stability de deployments. An image stream represents one or more sets of container images. Each set, or stream, is identified by an image stream tag. Para criaruma image stream, use o comando oc create is nome. Para criar tags, use o comando oc create istag nome_stream:tag --from-image image_link. Para usar image streams em deployments, basta criar uma no mesmo project que o deployment e, qndo no deployment object, referencie a stream como nome:tag ao inves do full image name do registry. Quando estiver criando um deployment, apenas use a option --image e especifique o nome e a tag igual o exemplo anterior.
        
        6.1) Image triggers: triggers são uma espécie de método para automatizar atualização de image streams, de modo que essas não atualizam automaticamente, diferentemente de imagens normais. Assim, para configurar um, basta usar o comando oc set triggers deployment/nome from-image nome:tag
        
        7. Security Context Constraints (SCCs) é um security mechanism do openshift que limita o acesso de running pods ao host environment. Além disso, SCCs controlam os recursos de: Running privileged containers, Requesting extra capabilities for a container, Using host directories as volumes, Changing the SELinux context of a container, Changing the user ID. O comando oc get scc mostra os security constraints que o openshift define.
        
        8. Cluster updates: existem vários métodos de atualizar seu cluster e atualizar operadores. 'Channels' é o nome dado a canais de atualização ou métodos de atualização.
        
        fast channel: atualiza com a latest possível;
        
        stable channel só atualiza dps da última versão ter sido testada várias vezes;
        
        candidate channel: vc usa uma versão de testes e share o feedback.
        
        Além disso, openshift não suporta rollback, ou seja, atualizar para uma earlier version. Um operator pode ter vários canais de atualização. Depende da escolha do seu criador. Para cada operator, vc pode decidir se a atualização (via OLM - operator lifecycle manager) é automatica ou requer a permissão do adm.
- - - - 2.1) create services: para criar um service, basta usar o comando oc expose deployment cite_nome_deployment junto de várias options:
        
        --port: especifica o port em que o service vai atuar.
        
        --target-port: especifica o nome ou numero do container port.
        
        --protocol: determines the network protocol for the service. TCP is used by default.
        
        --name: nomeia o service
        
        -o wide: mostra o selector que o service usa (?). ara ver o selector de qlqr pod, use oc describe deployment 'insira_nome
        
        2.2) Tipos de serviços: existem diversos tipos de serviços baseados no tipo de aplicação, infraestrutura do cluster e security requirements:
        
        ClusterIP: é o tipo default e ele exposes the service on a cluster IP address. Este é usado para rotear pod-para-pod e é o tipo de serviço certo para a maioria das aplicações;
        
        Load balancer: esse tipo de serviço torna a aplicação no cluster disponível para outras networks fora do cluster. Esse recurso, basicamente, instrui o openshift a ativar um load balancer no seu cloud environment e, daí, terá um endereço de IP externally accessible para a aplicação.
        
        ExternalIP: redireciona o tráfego do cluster node IP address para um pod. Porém, necessita allow direct network connections, o que é um security risk;
        
        NodePort: With this method, Kubernetes exposes a service on a port on the node IP address. The port is exposed on all cluster nodes, and each node redirects traffic to the endpoints (pods) of the service. Também necessita de direct network conection.
        
        ExternalName: ??
        
        2.3) services e routes: eles são diferentes de modo que Services provide network access between pods, whereas routes provide network access to pods from users and applications outside the cluster. Porém, eles estão interligados de modo que services e routes provêm network access e expõem the address e permitem a comunicação entre estruturas.
- - - - 4) Container Resource Requests: containers podem requerer recursos a mais para rodar suas aplicações. Para essas aplicações que requerem uma qntd específica de recursos é possível definir essa quantia na hora de fazer o deploy. Naturalmente, o container só precisa do mínimo de recursos necessários para rodar a aplicação, porém, qndo for set um numero de resources, sempre coloque o maior valor possível que a aplicação possa necessitar. Assim, usa-se milicores (para recursos do CPU) ou bytes (para recursos de memória). Um milicore é o equivalente a um pedaço do CPU core dividido em 1000 unidades. Ou seja, 1m = 0,001 de um Core de CPU. Para set um resource request para um pod, use o comando oc set resources, de tal maneira:
        oc set resources deployment deployment_name \
        --requests cpu=Xm,memory=Ygi
        Assim, use os comandos oc adm top node node_name e oc adm top pods --namespace project_name para ver a qntd de recursos utilizados no node/project, respectivamente. É possível usar, tbm o comando oc describe node para analisar requests e limits, entre outras coisas.
        
        4.1) Setting resource limits: Mesmo colocando um valor fixo de resources que o container pode consumir, isso não impede ele de acabar consumindo mais (por algum motivo). Assim, é necessário criar um memory limit e cpu limit.
        
        Memory Limit: é necessário qndo, por ex, houver um memory leak (um bug que faz com que um processo utilize uma qntd x de memória mas acaba não liberando ela após o fim do processo). Assim, use o comando:
        
        oc set resources deployment/nome \
        --limits memory=yGi
        
        CPU Limit: diferentemente da memória, se o uso disponível de cpu do container chegar ao limite, a aplicação não falhará, apenas ficará mais devagar. Assim, é necessário set um limit qndo vc precisar que uma aplicação tenha um behavior consistente ao longo de todo o seu processo. Assim, use o comando:
        
        oc set resources deployment/nome \
        --limits cpu=Xm
        
        4.2) Autoscalling: capacidade do openshift de, automaticamente, scale o valor de resource usage de cada deployment. Ele é ativado a cada 15 segundos e a ele damos o nome de Horziontal Pod Autoscaller (HPA). Para criar um, basta usar o comando
        oc autoscale deployment/nome \
        --min X -- max Y --cpu-percent Z
        Os valores de max e min representam numero de pods para criar para poder fazer um load balance. A parte do cpu-percent pode ser alterada tbm. Só coloquei pq foi o exemplo dado.
        Para pegar info do autoscaller, use oc get hpa.
- - - - 4) RBAC e quotas: identicamente às questões de resource management (de colocar limits e requerer cpu e memória) existe isso só que com um outro nome (e mais aprofundado) chamado quota. Ou seja, é possível fazer as mesmas coisas (limitar -- cpu ou memória // requerer -- cpu ou memória), só que de uma maneira diferente e mais aprofundada. Além disso, quotas possuem a capacidade de definir limites a resources, como deployments. Para isso, use o comando oc create resourcequota nome --hard=count/pods=x . PAra ver info sobre um quota criado, use o comando oc get quota. Resource quotas são um saco: ele não vai funcionar se uma pequena coisa ta errada. Assim, (infelizmente) siga esses passos qndo for criar uma: crie a quota em um testing evironment, para ensure que ela tenha sim o seu desired effect e, depois, review a quota com o oc get resourcequota. Assim, quotas servem para definir um padrão de limite e requests para todos os deployments em um namespace ou project. Só facilita as coisas. Outro jeito de criar quotas é usando o comando oc create quota nome --hard=requests.memory/cpu=xGi,limits.memory/cpu=xGi, que faz mais sentido
        
        5) Project Templates: esses são usados toda vez que se cria um template. É possível personalizar templates para que seu project já saia com as configurações certinhas (como qntd de resources que podem ser criados nele, qntos % de cpu ele pode usar no total -quotas-, adicionar roles, network policies e etc). Para isso, use o comando oc create -f template -n namespace_name. Para configurar seu template, edite a file projects.config.openshift.io/cluster e, na seção spec altere o que for necessário.
        
        5.1) Templates possuem muitas ultilidades e podem criar qualquer recurso do kubernetes. Um templat é o kubernetes equivalent ao recurso kustomize. Para avaliar um template já existente (os pré configurados ficam no openshift namespace) use o comando oc describe template template_name -n namespace_name. Para ver o manifest para o template, use o comando oc get template template-name -o yaml -n namespace. A option --template=nome do comando oc new-app é capaz de 'deploy' as configurações de um template dentro de um project, de modo que o comando final tenha a aparência: oc new-app --template=nome -p nome_project=nome_usuario (porém, lembre-se de que o comando new-app só pode criar novos recursos, e não update eles. Então, be careful which template to use). Use o comando
        oc process template_name -o yaml \
        -p sessão_para_alterar \
        -p sessão_para_alterar \
        > nome_template.yaml
        
        6) Helm: Helm is an open source application that helps to manage the lifecycle of Kubernetes applications. Helm introduz algo chamado charts. Esses definem recursos do kubernetes nos quais vc consegue deploy. Um helm chart é semelhante às imagens: ambos são criados pela comunidade e existem repositórios para eles, mas tbm charts can be distributed as files, archives, or container images. O helm é uma aplicação do CLI e possui os seguintes componentes:
        
        Charts: Charts are the packaged applications that the helm command deploys.
        
        Release: A release is the result of deploying a chart. You can deploy a chart many times to the same cluster. Each deployment is a different release.
        
        Para se referir a um chart, basta usar o absolute path de sua localização ou apenas um URL. Use o comando helm show para mostrar info sobre o chart. Para instalar/deploy um chart, basta especificar o target namespace, os valores do chart para alterar (possível fazer via yaml) e o release name. Use o comando helm list para listar os releses do seu cluster. O comando helm upgrade consegue update os releases e charts to the current version e, além disso, o comando helm rollback consegue 'desatualizar' para uma versão anterior descrita no comando helm history. POr fim, use o comando helm install release-name chart-reference para adicionar um release.
- - - - 4) Jenkins: é o leading opesn-source automation server. Supports building, deploying and automating any software development task. Termos/recursos essenciais do jenkins e seus conceitos:
        
        Project/Job: um script quue descreve o que o jenkins deve fazer, como por exemplo, construir uma aplicação.
        
        Pipeline: um tipo de job que descreve o que o jenkins deve fazer como uma sequência de passos em grouped stages.
        
        Build: A single execution of a project, including its runtime logs and output artifacts.
        
        Node: A server or container that runs builds.
        
        Worker: A thread in a master node that either runs a build or orchestrates available agents.
        
        Workspace: A file system folder, dedicated to a project and sometimes also to a node, where builds store data that is either temporary, or reused between multiple builds of the same project.
        
        Credential: A Jenkins construct that provides projects and builds with access credentials to external resources. There are different credentials to store user name and password pairs, SSH keys, and other credential types.
        
        Plug-in: Almost all of Jenkins functionality is extensible by plug-ins written in Java. There are many community plug-ins that support different kinds of nodes, credentials, and programming languages.
        
        Master node: Stores definitions of projects and their builds.
        
        Agent node: Run builds (or parts of a build) under the control of a master node.
        
        Uma instância do jenkins possui sempre apenas um master node e zero (ou mais) agent nodes. Você pode escolher entre duas versões já predefinidas no openshift para instalar um servidor jenkins: jenkins-ephemeral deploys a Jenkins server using ephemeral storage for quick testing e jenkins-persistent deploys a Jenkins server using persistent storage for development and production environments.
        
        5. Monitoring stack: alguns dos componenetes do monitoring stack são:
        
        Cluster monitoring operator (CMO): componente central da stack. Administra os monitoring componentes que foram deployed;
        
        Prometheus operator: deploy e configura o prometheus e alertmanager;
        
        prometheus: monitoring server;
        
        prometheus adapter: exposes cluster resourcers that are used for horizontal autoscaling (HPA);
        
        alertmanager: handles alerts sent by the prometheuus server;
        
        kube state metrics: exporta recursos kubernetes pro prometheus monitorar;
        
        openshift state metrics: mesmo que o anterior, so que openshift;
        
        Grafana: Grafana is a platform for analyzing and visualizing metrics. The Grafana dashboards provided with the monitoring stack are read-only.
        
        É necessário assign a role cluster-monitoring-view a um usuário para ele poder ver cluster alerts e metrics.