As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá. # Opções de instalação Há duas maneiras principais de instalar o Red Hat OpenShift em AWS: + Infraestrutura provisionada pelo instalador (IPI): o usuário fornece as informações básicas (como o número de máquinas do ambiente de gerenciamento) e pode escolher valores padrão para a maioria das perguntas. O Red Hat OpenShift Service on AWS Command Line Utility (`rosa`CLI) pode ser colocado em uma estrutura de IPI, conforme discutido na próxima seção. + Infraestrutura provisionada pelo usuário (UPI) — Todos os componentes da infraestrutura, como Servidor de Nomes de Domínio (DNS), nuvens privadas virtuais da Amazon VPCs (), máquinas de bootstrap e planos de controle são criados manualmente, e o OpenShift Red Hat é instalado em cima dessa infraestrutura. Ambas as configurações usam o mesmo programa de instalação (`install-config.yaml`), o qual instala componentes com base em destinos e dependências. Cada destino tem suas próprias dependências. Portanto, o programa pode oferecer suporte a vários destinos em paralelo e garantir que o destino possa executar o cluster com êxito. O diagrama a seguir mostra alguns dos destinos e dependências. ![Metas e dependências da Red Hat OpenShift em AWS](http://docs.aws.amazon.com/pt_br/prescriptive-guidance/latest/red-hat-openshift-on-aws-implementation/images/targets-dependencies.png) ## Vantagens e desvantagens de cada abordagem **** | Infraestrutura provisionada pelo instalador (IPI) | Infraestrutura provisionada pelo usuário (UPI) | | --- | --- | | Fácil de instalar. | Complexa, exige algum tempo para ser configurada. | | Não oferece muitas opções de personalização. | É possível personalizar a topologia e toda a infraestrutura. | | Suportes AWS e outras opções de nuvem pública. | Suporta VMware sistemas bare metal, bem como AWS outras opções de nuvem. | | Cria todos os componentes da infraestrutura, incluindo balanceadores de carga e redes virtuais. | Pode ser usada quando a plataforma subjacente não atende a todos os requisitos. (Por exemplo, sistemas bare metal não fornecem balanceadores de carga.) | | Altamente automatizada. | Exige a criação de toda a camada de automação para provisionar a infraestrutura subjacente. Você pode usar AWS CloudFormation modelos para essa finalidade. | | As verificações de pré-requisitos são fáceis de realizar. | Os pré-requisitos devem ser validados com cuidado. | ## Exemplo de IPI com a CLI do `rosa`: O Red Hat OpenShift Service on AWS implementa um tipo de instalação IPI, mas oferece benefícios adicionais. Você usa a `rosa` CLI para gerenciar (atualizar, excluir ou provisionar) um Red Hat OpenShift em AWS clusters e recursos. Para obter mais informações, consulte a [ OpenShift documentação da Red Hat](https://docs.openshift.com/rosa/rosa_getting_started/rosa-getting-started.html). Para provisionar um OpenShift cluster Red Hat AWS, primeiro você instala a `rosa` CLI e garante que o AWS Command Line Interface (AWS CLI) aponte para sua AWS conta. Você poderá então usar a CLI do `rosa` para realizar validações e provisionar o cluster usando comandos semelhantes aos descritos a seguir. ``` rosa verify permissions [arguments] rosa download oc rosa verify quota [arguments] rosa init --token= rosa create cluster --cluster-name= ``` Quando o cluster tiver sido provisionado, você poderá verificá-lo usando OpenShift comandos. ``` oc get nodes (list all nodes if connected to cluster) oc get ns (list all namespaces) ``` Para obter mais informações, consulte a [documentação do OpenShift ](https://docs.openshift.com/rosa/cli_reference/openshift_cli/getting-started-cli.html). Os benefícios de usar este método incluem: + Facilidade para configurar e provisionar rapidamente o cluster na AWS. + Fornecimento de informações do log; é fácil solucionar problemas quando algo errado ocorre. + Permite validar pré-requisitos via linha de comando. + Também pode ser usado para exclusões e outras operações. Algumas preocupações possíveis: + As opções de personalização podem ser limitadas. + Requer a `rosa` CLI e AWS CLI outras configurações básicas. + Todos os desafios do modelo IPI também se aplicam ao uso da CLI do `rosa`. ## Exemplo de IPI: uso de `openshift-install` O `openshift-install` é um utilitário de linha de comando que pode ser usado para criar um cluster rapidamente. Esse comando fornece alguma flexibilidade por meio de modificações no arquivo `install-config.yaml`. Esta seção fornece etapas de alto nível para uso do utilitário. Para obter etapas detalhadas de instalação, consulte a [OpenShift documentação](https://docs.openshift.com/container-platform/4.6/installing/installing_aws/installing-aws-default.html). 1. Faça download do instalador do [site da Red Hat](https://console.redhat.com/openshift/install) (requer uma conta Red Hat). 1. Descompacte o pacote. ``` tar xvf openshift-install-linux.tar.gz ``` 1. Identifique o diretório de instalação e execute o comando `create cluster`. ``` ./openshift-install create cluster --dir --log-level=info ``` 1. Para personalizar a instalação, gere o arquivo `install-config.yaml`. ``` ./openshift-install create install-config --dir ``` O exemplo a seguir é um trecho de um arquivo `install-config.yaml` de exemplo. Para ver as opções de configuração, consulte a [OpenShift documentação](https://docs.openshift.com/container-platform/4.7/installing/installing_aws/installing-aws-customizations.html). ``` apiVersion: v1 baseDomain: sample.com credentialsMode: Mint controlPlane: hyperthreading: Enabled name: master platform: aws: zones: - us-east-2a - us-east-2b rootVolume: iops: 4000 size: 500 type: io1 type: m5.xlarge replicas: 3 compute: - hyperthreading: Enabled name: worker platform: aws: rootVolume: iops: 2000 size: 500 type: io1 type: c5.4xlarge zones: - us-east-2c replicas: 3 metadata: name: sample-cluster networking: clusterNetwork: - cidr: 10.128.0.0/14 hostPrefix: 23 machineNetwork: - cidr: 10.0.0.0/16 networkType: OpenShiftSDN serviceNetwork: - 172.30.0.0/16 platform: aws: region: us-west-2 userTags: adminContact: jdoe costCenter: 7536 amiID: ami-96c6f8f7 serviceEndpoints: - name: ec2 url: https://vpce-id.ec2.us-west-2.vpce.amazonaws.com fips: false sshKey: ssh-ed25519 AAAA... pullSecret: '{"auths": ...}' ``` ## Exemplo de UPI — instalação em infraestrutura provisionada pelo usuário AWS Você pode provisionar um OpenShift cluster Red Hat em uma AWS infraestrutura existente que você provisiona separadamente. Para provisionar a infraestrutura, você pode usar CloudFormation modelos para criar a VPC, a zona hospedada, os registros DNS e outros componentes. Para etapas e CloudFormation modelos detalhados, consulte a [OpenShift documentação](https://docs.redhat.com/en/documentation/openshift_container_platform/4.1/html/installing/installing-on-user-provisioned-aws). Quando o cluster for provisionado, você deverá aprovar todas as solicitações de assinatura de certificado (CSRs) para mover os nós de trabalho para um status. `Ready` ``` oc get nodes NAME STATUS ROLES AGE VERSION master-0 Ready master 63m v1.13.4+b626c2fe1 master-1 Ready master 63m v1.13.4+b626c2fe1 master-2 Ready master 64m v1.13.4+b626c2fe1 worker-0 NotReady worker 76s v1.13.4+b626c2fe1 worker-1 NotReady worker 70s v1.13.4+b626c2fe1 ``` É possível visualizar todos os certificados em uma só etapa usando o comando a seguir. ``` oc get csr -ojson | jq -r '.items[] | select(.status == {} ) | .metadata.name' | xargs oc adm certificate approve ``` Você pode verificar se todos os operadores estão no estágio `Ready` usando a linha de comando do `oc` ou via console do Red Hat. Após a verificação, os recursos de bootstrap podem ser excluídos. Você pode determinar a `stack-name` partir do Console de gerenciamento da AWS, e do nome que você forneceu ao criar a pilha. ``` aws cloudformation delete-stack --stack-name ``` Conclua o provisionamento do cluster usando o comando a seguir. ``` ./openshift-install --dir= wait-for install-complete INFO Waiting up to 30m0s for the cluster to initialize... ``` Certifique-se de verificar os logs e confirmar se não há erros antes de entregar o cluster às partes interessadas.