**Ajudar a melhorar esta página**
Para contribuir com este guia de usuário, escolha o link **Editar esta página no GitHub**, disponível no painel direito de cada página.
# Criar nós com AMIs do Amazon Linux otimizadas
O Amazon Elastic Kubernetes Service (Amazon EKS) fornece imagens de máquina da Amazon (AMIs) especializadas e otimizadas para a execução de nós de processamento do Kubernetes. Estas AMIs do Amazon Linux (AL) otimizadas para o EKS são configuradas previamente com componentes essenciais, como `kubelet`, o AWS IAM Authenticator e o `containerd`, para garantir a integração sem complicações e a segurança em seus clusters. Este guia apresenta detalhes sobre as versões de AMI disponíveis e fornece uma visão geral das opções especializadas para computação acelerada e para arquiteturas baseadas em ARM.
## Considerações
+ É possível acompanhar os eventos de segurança ou privacidade do Amazon Linux no [centro de segurança do Amazon Linux](https://alas.aws.amazon.com/), selecionando a guia da versão desejada. Você também pode assinar o feed RSS aplicável. Os eventos de segurança e privacidade incluem uma visão geral do problema, quais pacotes são afetadas e como atualizar suas instâncias para corrigir o problema.
+ Antes de fazer a implantação de uma AMI baseada em ARM ou acelerada, analise as informações contidas em [AMIs do Amazon Linux aceleradas e otimizadas para o Amazon EKS](#gpu-ami) e [AMIs do Amazon Linux baseadas em ARM e otimizadas para o Amazon EKS](#arm-ami).
+ As instâncias `P2` do Amazon EC2 não são compatíveis com o Amazon EKS porque exigem a versão 470 ou anterior do driver `NVIDIA`.
+ Todos os grupos de nós gerenciados recém-criados em clusters na versão `1.30` ou mais recente terão como padrão automático o uso do AL2023 como sistema operacional do nó.
## AMIs do Amazon Linux aceleradas e otimizadas para o Amazon EKS
As AMIs do Amazon Linux (AL) aceleradas e otimizadas para o Amazon EKS são baseadas nas AMIs padrão do Amazon Linux otimizadas para o EKS. Elas são configuradas para servir como imagens opcionais para nós do Amazon EKS para serem compatíveis com workloads baseadas em GPU, no [Inferentia](https://aws.amazon.com/machine-learning/inferentia/) e no [Trainium](https://aws.amazon.com/machine-learning/trainium/).
Para obter mais informações, consulte [Uso de AMIs aceleradas e otimizadas para o EKS em instâncias de GPU](ml-eks-optimized-ami.md).
## AMIs do Amazon Linux baseadas em ARM e otimizadas para o Amazon EKS
As instâncias Arm oferecem uma economia significativa para aplicações de expansão e baseadas no Arm, como servidores Web, microsserviços conteinerizados, frotas de armazenamento em cache e datastores distribuídos. Ao adicionar nós do Arm ao cluster, revise as considerações a seguir.
+ Se o cluster tiver sido implantado antes de 17 de agosto de 2020, será necessário fazer uma atualização única dos manifestos essenciais do complemento de cluster. Isso serve para que o Kubernetes possa extrair a imagem correta para cada arquitetura de hardware em uso em seu cluster. Para obter mais informações sobre como atualizar complementos do cluster, consulte [Etapa 1: preparar-se para o upgrade](update-cluster.md#update-existing-cluster). Se você implantou o cluster depois de 17 de agosto de 2020, então o plug-in CNI do CoreDNS, `kube-proxy` e Amazon VPC para complementos do Kubernetes já tem capacidade para várias arquiteturas.
+ As aplicações implantadas em nós do Arm devem ser compiladas para Arm.
+ Se tiver DaemonSets implantados em um cluster existente, ou se quiser implantá-los em um novo cluster em que também queira implantar nós do Arm, verifique se o DaemonSet pode ser executado em todas as arquiteturas de hardware do cluster.
+ Você pode executar grupos de nós do Arm e grupos de nós x86 no mesmo cluster. Caso o faça, considere implantar imagens de contêiner de várias arquiteturas em um repositório de contêineres, como o Amazon Elastic Container Registry, e depois adicionar seletores de nós aos manifestos para que o Kubernetes saiba em que arquitetura de hardware um pod pode ser implantado. Para obter mais informações, consulte [Enviar uma imagem de várias arquiteturas](https://docs.aws.amazon.com/AmazonECR/latest/userguide/docker-push-multi-architecture-image.html) no *Guia do usuário do Amazon ECR* e a publicação de blog [Introducing multi-architecture container images for Amazon ECR](https://aws.amazon.com/blogs/containers/introducing-multi-architecture-container-images-for-amazon-ecr).
## Mais informações
Para obter mais informações sobre o uso de AMIs do Amazon Linux otimizadas para o Amazon EKS, consulte as seguintes seções:
+ Para usar o Amazon Linux com grupos de nós gerenciados, consulte [Simplificar o ciclo de vida dos nós com grupos de nós gerenciados](managed-node-groups.md).
+ Para iniciar nós autogerenciados do Amazon Linux, consulte [Recuperar IDs de AMI do Amazon Linux recomendadas](retrieve-ami-id.md).
+ Para obter informações sobre versões, consulte [Recuperar informações da versão da AMI do Amazon Linux](eks-linux-ami-versions.md).
+ Para recuperar os IDs mais recentes das AMIs do Amazon Linux otimizadas para o Amazon EKS, consulte [Recuperar IDs de AMI do Amazon Linux recomendadas](retrieve-ami-id.md).
+ Para acessar os scripts de código aberto utilizados na criação das AMIs otimizadas para o Amazon EKS, consulte [Desenvolvimento de uma AMI do Amazon Linux personalizada e otimizada para o EKS](eks-ami-build-scripts.md).
# Atualização do Amazon Linux 2 para o Amazon Linux 2023
**Atenção**
A partir de 26 de novembro de 2025, a Amazon EKS não publica mais AMIs do Amazon Linux 2 (AL2) otimizadas para o EKS. As AMIs baseadas no AL2023 e no Bottlerocket para o Amazon EKS estão disponíveis para todas as versões compatíveis com Kubernetes, incluindo a versão 1.33 e as versões posteriores.
O AL2023 é um sistema operacional baseado no Linux que foi projetado para fornecer um ambiente seguro, estável e de alta performance para as aplicações em nuvem. Ele corresponde à próxima geração do Amazon Linux da Amazon Web Services e está disponível em todas as versões do Amazon EKS com suporte.
O AL2023 oferece diversas melhorias em relação ao AL2. Para obter uma comparação completa, consulte [Comparing AL2 and Amazon Linux 2023](https://docs.aws.amazon.com/linux/al2023/ug/compare-with-al2.html) no *Guia do usuário do Amazon Linux 2023*. Vários pacotes foram adicionados, atualizados e removidos em relação ao AL2. É altamente recomendável testar as aplicações com o AL2023 antes de realizar a atualização. Para obter uma lista de todas as alterações de pacote no AL2023, consulte [Package changes in Amazon Linux 2023](https://docs.aws.amazon.com/linux/al2023/release-notes/compare-packages.html) nas *Notas de lançamento do Amazon Linux 2023*.
Além dessas alterações, é necessário estar ciente do seguinte:
+ O AL2023 introduz um novo processo de inicialização do nó `nodeadm` que usa um esquema de configuração YAML. Se estiver usando grupos de nós autogerenciados ou uma AMI com um modelo de inicialização, será necessário fornecer, de forma explícita, metadados de cluster adicionais ao criar um novo grupo de nós. Veja a seguir um [exemplo](https://awslabs.github.io/amazon-eks-ami/nodeadm/) dos parâmetros mínimos necessários, em que `apiServerEndpoint`, `certificateAuthority` e `cidr` do serviço passaram a ser necessários:
```
---
apiVersion: node.eks.aws/v1alpha1
kind: NodeConfig
spec:
cluster:
name: my-cluster
apiServerEndpoint: https://example.com
certificateAuthority: Y2VydGlmaWNhdGVBdXRob3JpdHk=
cidr: 10.100.0.0/16
```
No AL2, os metadados desses parâmetros eram revelados na chamada de API `DescribeCluster` do Amazon EKS. Com o AL2023, esse comportamento foi alterado, uma vez que a chamada de API adicional corre o risco de sofrer controle de utilização durante grandes aumentos de escala vertical para nós. Essa alteração não afetará você se estiver usando grupos de nós gerenciados sem um modelo de inicialização ou se estiver usando o Karpenter. Para obter mais informações sobre `certificateAuthority` e sobre o serviço de `cidr`, consulte [https://docs.aws.amazon.com/eks/latest/APIReference/API_DescribeCluster.html](https://docs.aws.amazon.com/eks/latest/APIReference/API_DescribeCluster.html) na *Referência de API do Amazon EKS*.
+ Para o AL2023, o `nodeadm` também altera o formato para aplicar parâmetros ao `kubelet` para cada nó usando [https://awslabs.github.io/amazon-eks-ami/nodeadm/doc/api/#nodeconfigspec](https://awslabs.github.io/amazon-eks-ami/nodeadm/doc/api/#nodeconfigspec). No AL2, isso era feito com o parâmetro `--kubelet-extra-args`. Isso é comumente usado para adicionar rótulos e taints aos nós. Um exemplo abaixo mostra a aplicação de `maxPods` e `--node-labels` ao nó.
```
---
apiVersion: node.eks.aws/v1alpha1
kind: NodeConfig
spec:
cluster:
name: test-cluster
apiServerEndpoint: https://example.com
certificateAuthority: Y2VydGlmaWNhdGVBdXRob3JpdHk=
cidr: 10.100.0.0/16
kubelet:
config:
maxPods: 110
flags:
- --node-labels=karpenter.sh/capacity-type=on-demand,karpenter.sh/nodepool=test
```
+ A versão `1.16.2` ou as versões posteriores do plug-in CNI da Amazon VPC são necessárias para o AL2023.
+ O AL2023 requer `IMDSv2` por padrão. O `IMDSv2` tem diversos benefícios que ajudam a aprimorar a postura de segurança. Ele usa um método de autenticação orientado por sessão que requer a criação de um token secreto em uma solicitação HTTP PUT simples para iniciar a sessão. O token de uma sessão pode ter validade de um segundo a seis horas. Para obter mais informações sobre como fazer a transição do `IMDSv1` para o `IMDSv2`, consulte [Transition to using Instance Metadata Service Version 2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-metadata-transition-to-version-2.html) e [Get the full benefits of IMDSv2 and disable IMDSv1 across your AWS infrastructure](https://aws.amazon.com/blogs/security/get-the-full-benefits-of-imdsv2-and-disable-imdsv1-across-your-aws-infrastructure). Se desejar usar o `IMDSv1`, você ainda poderá fazê-lo ao substituir manualmente as configurações usando as propriedades de inicialização da opção de metadados da instância.
**nota**
Para `IMDSv2` com AL2023, a contagem de saltos padrão para os grupos de nós gerenciados pode variar:
Quando não estiver usando um modelo de lançamento, o padrão será definido como `1`. Isso significa que os contêineres não terão acesso às credenciais do nó usando o IMDS. Se você precisar de acesso de contêiner às credenciais do nó, ainda poderá obtê-lo usando um [modelo de execução personalizado do Amazon EC2](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-ec2-launchtemplate-metadataoptions.html).
Ao usar uma AMI personalizada em um modelo de execução, o padrão `HttpPutResponseHopLimit` será definido como `2`. É possível substituir manualmente o `HttpPutResponseHopLimit` no modelo de execução.
Como alternativa, é possível usar a [Identidade de Pods do Amazon EKS](pod-identities.md) para fornecer credenciais em vez de usar o `IMDSv2`.
+ O AL2023 apresenta a próxima geração de hierarquia de grupo de controle unificada (`cgroupv2`). A hierarquia `cgroupv2` é usada para implementar um runtime de contêiner e usar `systemd`. Embora o AL2023 ainda inclua códigos que podem fazer o sistema funcionar ao usar `cgroupv1`, esta não é uma configuração recomendada ou com suporte. Essa configuração será completamente removida em uma versão principal futura do Amazon Linux.
+ O `eksctl` versão `0.176.0` ou superior é necessário para o `eksctl` oferecer suporte ao AL2023.
Para grupos de nós gerenciados anteriormente existentes, é possível realizar uma atualização no local ou uma atualização azul/verde, dependendo de como você está usando um modelo de inicialização:
+ Caso esteja usando uma AMI personalizada com um grupo de nós gerenciados, será possível realizar uma atualização local ao alterar o ID da AMI no modelo de inicialização. É necessário garantir que as aplicações e quaisquer dados do usuário sejam transferidos para o AL2023 antes de executar essa estratégia de atualização.
+ Se você estiver usando grupos de nós gerenciados com o modelo de inicialização padrão ou com um modelo de inicialização personalizado que não especifica o ID da AMI, será necessário fazer upgrade usando uma estratégia azul/verde. Uma atualização azul/verde, normalmente, é mais complexa e envolve a criação de um grupo de nós totalmente novo no qual você especificaria o AL2023 como o tipo de AMI. O novo grupo de nós precisará ser configurado cuidadosamente para garantir que todos os dados personalizados do grupo de nós do AL2 sejam compatíveis com o novo sistema operacional. Depois que o novo grupo de nós tiver sido testado e validado com as aplicações, os pods poderão ser migrados do grupo de nós antigo para o novo grupo de nós. Depois que a migração for concluída, será possível excluir o grupo de nós antigo.
Se estiver usando o Karpenter e desejar usar o AL2023, você precisará modificar o campo `EC2NodeClass` `amiFamily` com o AL2023. Por padrão, a Oscilação está habilitada no Karpenter. Isso significa que assim que o campo `amiFamily` for alterado, o Karpenter atualizará automaticamente os nós de processamento para a AMI mais recente, quando disponível.
## Informações adicionais sobre o nodeadm
Ao utilizar uma AMI do Amazon Linux 2023 otimizada para EKS ou criar uma AMI personalizada do EKS Amazon Linux 2023 por meio dos scripts do Packer fornecidos no repositório oficial amazon-eks-ami do GitHub, será necessário evitar executar explicitamente nodeadm init nos dados do usuário do EC2 ou como parte da sua AMI personalizada.
Se você quiser gerar um NodeConfig dinâmico em seus dados de usuário, é possível gravar essa configuração em um arquivo yaml ou json drop-in em `/etc/eks/nodeadm.d`. Esses arquivos de configuração serão mesclados e aplicados ao seu nó quando a inicialização do nodeadm for iniciada automaticamente, posteriormente no processo de inicialização. Por exemplo:
```
cat > /etc/eks/nodeadm.d/additional-node-labels.yaml << EOF
apiVersion: node.eks.aws/v1alpha1
kind: NodeConfig
spec:
kubelet:
flags:
- --node-labels=foo=bar
EOF
```
As AMIs do Amazon Linux 2023 otimizadas para EKS executam automaticamente a inicialização do nodeadm em duas fases por meio de serviços systemd separados: nodeadm-config é executado antes da execução dos dados do usuário, enquanto nodeadm-run é executado depois. O serviço nodeadm-config estabelece configurações básicas para containerd e kubelet antes da execução dos dados do usuário. O serviço nodeadm-run executa alguns daemons do sistema e conclui todas as configurações finais após a execução dos dados do usuário. Se o comando de inicialização do nodeadm for executado mais uma vez, por meio de dados do usuário ou de uma AMI personalizada, ele poderá quebrar as suposições sobre a ordem de execução, levando a resultados inesperados, incluindo ENIs configurados incorretamente.
# Recuperar informações da versão da AMI do Amazon Linux
O versionamento das AMIs do Amazon Linux otimizadas para o Amazon EKS é feito com base na versão do Kubernetes e na data de lançamento da AMI, no seguinte formato:
```
k8s_major_version.k8s_minor_version.k8s_patch_version-release_date
```
Cada versão da AMI inclui várias versões do [kubelet](https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet/), do kernel do e do [containerd](https://containerd.io/). As AMIs aceleradas também incluem várias versões do driver NVIDIA. Você pode encontrar essas informações de versão no [Changelog](https://github.com/awslabs/amazon-eks-ami/blob/main/CHANGELOG.md) no GitHub.
# Recuperar IDs de AMI do Amazon Linux recomendadas
Ao implantar nós, é possível especificar um ID para uma imagem de máquina da Amazon (AMI) pré-compilada e otimizada para o Amazon EKS. Para recuperar um ID de AMI que se ajuste à configuração desejada, consulte a API AWS Systems Manager Parameter Store. O uso dessa API elimina a necessidade de pesquisar manualmente IDs de AMIs otimizadas para o Amazon EKS. Para obter mais informações, consulte [GetParameter](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_GetParameter.html). A [entidade principal do IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal) que você usou deve ter a permissão `ssm:GetParameter` do IAM para recuperar os metadados da AMI otimizada para o Amazon EKS.
Você pode recuperar o ID de imagem da mais recente AMI do Amazon Linux recomendada otimizada para o Amazon EKS com o comando a seguir, que usa o subparâmetro `image_id`. Faça as seguintes modificações no comando, conforme necessário, e execute o comando atualizado:
+ Substitua `` por uma [versão compatível do Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html).
+ Substitua *ami-type* por uma das seguintes opções. Para obter mais informações sobre os tipos de instâncias do Amazon EC2, consulte [Tipos de instância do Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-types.html).
+ Use *amazon-linux-2023/x86\$164/standard* para instâncias baseadas no Amazon Linux 2023 (AL2023) `x86`.
+ Use *amazon-linux-2023/arm64/standard* para instâncias ARM do AL2023, como as instâncias baseadas no [AWS Graviton](https://aws.amazon.com/ec2/graviton/).
+ Use *amazon-linux-2023/x86\$164/nvidia* para as instâncias `x86` baseadas do NVIDIA do AL2023 aprovadas mais recentemente.
+ Use *amazon-linux-2023/arm64/nvidia* para as instâncias `arm64` do NVIDIA do AL2023 aprovadas mais recentemente.
+ Use *amazon-linux-2023/x86\$164/neuron* para as instâncias mais recentes do AL2023 [AWS Neuron](https://aws.amazon.com/machine-learning/neuron/).
+ Substitua `` por uma [região da AWS compatível com o Amazon EKS](https://docs.aws.amazon.com/general/latest/gr/eks.html) para a qual você deseja o ID da AMI.
```
aws ssm get-parameter --name /aws/service/eks/optimized-ami///recommended/image_id \
--region --query "Parameter.Value" --output text
```
Aqui está um exemplo de comando após as substituições do espaço reservado terem sido feitas.
```
aws ssm get-parameter --name /aws/service/eks/optimized-ami/1.31/amazon-linux-2023/x86_64/standard/recommended/image_id \
--region us-west-2 --query "Parameter.Value" --output text
```
Veja abaixo um exemplo de saída.
```
ami-1234567890abcdef0
```
# Desenvolvimento de uma AMI do Amazon Linux personalizada e otimizada para o EKS
**Atenção**
A partir de 26 de novembro de 2025, a Amazon EKS não publica mais AMIs do Amazon Linux 2 (AL2) otimizadas para o EKS. As AMIs baseadas no AL2023 e no Bottlerocket para o Amazon EKS estão disponíveis para todas as versões compatíveis com Kubernetes, incluindo a versão 1.33 e as versões posteriores.
O Amazon EKS fornece scripts de desenvolvimento de código aberto no repositório [Amazon EKS AMI Build Specification](https://github.com/awslabs/amazon-eks-ami) que você pode usar para visualizar as configurações do `kubelet`, do runtime e do AWS IAM Authenticator for Kubernetes, além de criar sua própria AMI baseada no AL do zero.
Este repositório contém o [script de inicialização especializado para AL2](https://github.com/awslabs/amazon-eks-ami/blob/main/templates/al2/runtime/bootstrap.sh) e a [ferramenta nodeadm para AL2023](https://awslabs.github.io/amazon-eks-ami/nodeadm/), que são executados no momento da inicialização. Esses scripts configuram os dados de certificado da instância, o endpoint do ambiente de gerenciamento, o nome do cluster e muito mais. Os scripts são considerados a fonte de verdade para os desenvolvimentos de AMIs otimizadas para o Amazon EKS, portanto, você pode acompanhar o repositório do GitHub para monitorar as alterações em nossas AMIs.
Ao criar AMIs personalizadas usando AMIs otimizadas para o EKS como base, não é recomendado nem suportado executar uma atualização do sistema operacional (por exemplo, `dnf upgrade`) ou atualizar qualquer um dos pacotes do Kubernetes ou de GPU incluídos nas AMIs otimizadas para o EKS, pois isso pode comprometer a compatibilidade entre os componentes. Se você optar por atualizar o sistema operacional ou os pacotes incluídos nas AMIs otimizadas para o EKS, é recomendável realizar testes completos em um ambiente de desenvolvimento ou de preparação antes da implantação em um ambiente de produção.
Ao criar AMIs personalizadas para instâncias de GPU, recomenda-se desenvolver AMIs personalizadas distintas para cada geração e família de instâncias que você pretende executar. As AMIs aceleradas e otimizadas para o EKS realizam a instalação seletiva de drivers e pacotes durante o runtime, de acordo com a geração e a família do tipo de instância subjacente. Para obter mais informações, consulte os scripts de [instalação](https://github.com/awslabs/amazon-eks-ami/blob/main/templates/al2023/provisioners/install-nvidia-driver.sh) e de [runtime](https://github.com/awslabs/amazon-eks-ami/blob/main/templates/al2023/runtime/gpu/nvidia-kmod-load.sh) das AMIs do EKS.
## Pré-requisitos
+ [Instalar a AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-files.html)
+ [Instalar o HashiCorp Packer v1.9.4\$1](https://developer.hashicorp.com/packer/downloads)
+ [Instalar o GNU Make](https://www.gnu.org/software/make/)
## Início rápido
Este guia de início rápido apresenta os comandos para criar uma AMI personalizada na conta da AWS. Para saber mais sobre as configurações disponíveis para personalizar sua AMI, consulte as variáveis de modelo na página [Amazon Linux 2023](https://awslabs.github.io/amazon-eks-ami/usage/al2023/).
### Pré-requisitos
Instale o [plug-in da Amazon](https://developer.hashicorp.com/packer/integrations/hashicorp/amazon) necessário. Por exemplo:
```
packer plugins install github.com/hashicorp/amazon
```
### Etapa 1. Configurar o ambiente
Clone ou bifurque o repositório oficial de AMIs do Amazon EKS. Por exemplo:
```
git clone https://github.com/awslabs/amazon-eks-ami.git
cd amazon-eks-ami
```
Verifique se o Packer está instalado:
```
packer --version
```
### Etapa 2. Criar uma AMI do personalizada
Veja a seguir exemplos de comando de várias AMIs personalizadas.
**AMI do NVIDIA AL2 básica:**
```
make k8s=1.31 os_distro=al2 \
enable_accelerator=nvidia \
nvidia_driver_major_version=560 \
enable_efa=true
```
**AMI do NVIDIA AL2023 básica:**
```
make k8s=1.31 os_distro=al2023 \
enable_accelerator=nvidia \
nvidia_driver_major_version=560 \
enable_efa=true
```
**AMI do Neuron AL2023 compatível com STIG:**
```
make k8s=1.31 os_distro=al2023 \
enable_accelerator=neuron \
enable_fips=true \
source_ami_id=ami-0abcd1234efgh5678 \
kms_key_id=alias/aws-stig
```
Depois de executar esses comandos, o Packer fará o seguinte: \$1 Executará uma instância temporária do Amazon EC2. \$1 Instalará componentes, drivers e configurações do Kubernetes. \$1 Criará a AMI em sua conta da AWS.
A saída esperada deve ser semelhante a essa:
```
==> Wait completed after 8 minutes 42 seconds
==> Builds finished. The artifacts of successful builds are:
--> amazon-ebs: AMIs were created:
us-west-2: ami-0e139a4b1a7a9a3e9
--> amazon-ebs: AMIs were created:
us-west-2: ami-0e139a4b1a7a9a3e9
--> amazon-ebs: AMIs were created:
us-west-2: ami-0e139a4b1a7a9a3e9
```
### Etapa 3. Visualizar valores padrão
Para visualizar valores padrão e opções adicionais, execute o seguinte comando:
```
make help
```