---
sourceDocument: Capacidades da Now Platform da Yokohama
sourceDocumentLink: https://servicenow-prod.fluidtopics.net/r/pt-BR/yokohama/servicenow-platform

 Release :

    - yokohama

ft:locale :

    - pt-BR

ft:publication_title :

    - Capacidades da Now Platform da Yokohama

ft:clusterId :

    - platcap

bundleId :

    - platcap

workflow :

    - Platform


---

# Criar imagem do Docker do MID Server para Linux

# Criar imagem do Docker do MID Server para Linux {#ariaid-title1}

* Versão de lançamento: Yokohama
* 
* Atualizado 30 de jan. de 2025
* 
* ![](https://www.servicenow.com/docs/portal-asset/ico-clock) 13 min. de leitura

Implante MID Servers em contêineres no Linux criando uma imagem do Docker com as receitas fornecidas. O MID Server em contêiner usa uma imagem do Docker do MID Server que permite implantar MID Servers rapidamente.

## Antes de Iniciar

Função necessária: administrador

|-|
|   |
[ ]

{#mid-build-docker-linux__table_p53_ms4_nhb}

Pré-requisitos:

O host deve usar o [mecanismo Docker e a interface de linha de comando (CLI) 20.10.4 ou posterior](https://docs.docker.com/desktop/install/linux-install/).

Atualize a biblioteca para a versão mais recente disponível ou pelo menos a versão mais recente com uma correção de segurança. Se os problemas identificados fizerem parte de uma dependência transitiva, encontre uma versão da biblioteca dependente que inclua uma versão transitiva mais recente. Se a dependência transitiva não puder ser atualizada atualizando a biblioteca dependente, considere excluir a dependência e incluir diretamente uma versão segura.  
Nota:  
Verifique a disponibilidade do docker executando o comando de versão do docker como administrador. Consulte a [documentação do comando de versão do docker](https://docs.docker.com/engine/reference/commandline/version/) para obter mais informações.

## Procedimento

1. Baixe o arquivo ZIP da receita do Linux Docker na página de download do MID Server e verifique sua assinatura.  
   Para obter mais informações sobre a página de download do MID Server e a verificação de assinatura, consulte [Baixar arquivos do MID Server](https://servicenow-prod.fluidtopics.net/cC16zb6KMWu2b2TPMr2xhQ#t_DownloadMIDServerFiles__postreq_znq_nzd_mgb).
2. Descompacte o arquivo ZIP para uma pasta.
3. **Opcional:** Você pode mudar o diretório atual para a nova pasta.
4. Para criar uma imagem, execute o comando build: \> docker build \<path-to-docker-recipe\> \[ --tag \<docker-tag\> \]  
   Para obter mais informações sobre o comando, consulte a [documentação do comando build do Docker](https://docs.docker.com/engine/reference/commandline/build/). O caminho para o arquivo do Docker pode ser um caminho relativo ou o diretório atual se o arquivo estiver no diretório de receitas do Docker.

   A tag de imagem padrão é fornecida pronta para uso no arquivo .env com o parâmetro DOCKER_TAG. Você pode exportar este parâmetro antes de executar qualquer comando do docker, executando o comando: \> export $(grep DOCKER_TAG .env). Você pode substituir\<docker-tag\> com o valor \<docker-tag\> com o valor DOCKER_TAG em todos os comandos a seguir.

   O comando criar usa os seguintes argumentos:
   {#mid-build-docker-linux__id_exp_hmz_z5b__entry__2}

   | Propriedade | Descrição |
   |-|-|
   | MID_INSTALLATION_URL | O link para fazer o download do arquivo de instalação do MID Server. Por padrão, ele é definido como o link de download do arquivo ZIP de instalação do Linux 64 bits fornecido na página de download do MID Server. |
   | MID_INSTALLATION_FILE | O nome de um arquivo de instalação do MID Server local. O valor padrão está vazio. Se este parâmetro não estiver vazio, a receita vai usar o arquivo local em vez de baixá-lo do servidor de instalação. Este parâmetro usa somente o nome do arquivo, não o caminho completo. Antes da compilação, o arquivo local deve ser copiado para a subpasta asset/ do diretório da receita. Versões do MID Server anteriores a Rome não são compatíveis. Por exemplo: `> docker build <path-to-dockerfile> --build-arg MID_INSTALLATION_FILE=<mid.installation.file.name>) --tag <docker-tag>` |
   | MID_SIGNATURE_VERIFICATION | A assinatura do arquivo de instalação do MID Server deve ser verificada. O valor padrão é VERDADEIRO. Se for VERDADEIRO, o processo de compilação sempre vai verificar a assinatura digital do arquivo de instalação do MID Server, tenha sido baixado de um arquivo remoto ou local. Caso contrário, a verificação de assinatura vai ser ignorada. Por exemplo: `> docker build <path-to-dockerfile> --build-arg MID_SIGNATURE_VERIFICATION=false --tag <docker-tag>` |
   | USER_ID e GROUP_ID | Por padrão, quando não especificado, o Docker cria um usuário do MID Server com id de usuário = 1001 e id de grupo = 1001. Você pode passar um id de usuário personalizado e um id de grupo para o contêiner usando os argumentos de compilação USER_ID e GROUP_ID. O Docker cria um usuário para o MID Server com o id de usuário e o id de grupo fornecidos. Dentro da imagem do contêiner, todos os arquivos na pasta de instalação MID Server pertencem a este usuário e ao grupo raiz (id = 0). Quando a imagem é implantada na plataforma Kubernetes, este usuário MID Server se torna o usuário do contêiner que executa o MID Server. Quando a imagem é implantada em uma plataforma OpenShift, o OpenShift pode atribuir um ID de usuário arbitrário não administrador como o usuário do contêiner que executa o MID Server. No entanto, esse usuário sempre pertence ao grupo raiz. Em ambos os casos, o usuário do contêiner tem acesso total aos arquivos MID Server. Dessa forma, a mesma imagem pode ser implantada no Kubernetes e no OpenShift. |
   [ ]

   {#mid-build-docker-linux__id_exp_hmz_z5b}
5. **Opcional:** Depois que a imagem é criada com sucesso, você pode listar a imagem criada com o comando: \> docker image ls
{#mid-build-docker-linux__steps_x2t_21h_ypb}

## O que Fazer Depois

Para economizar espaço em disco, se houver imagens não utilizadas ou intermediárias, execute os seguintes comandos para remover essas imagens pendentes:

    $ docker rmi $(docker images --filter "dangling=true" -q --no-trunc)

Por exemplo, antes de remover imagens pendentes, o comando `docker image ls` pode mostrar algo semelhante ao seguinte:

    REPOSITORY                                TAG                                           IMAGE ID       CREATED              SIZE
    mid                                       trackdiscocopper-10-09-2020_10-14-2021_2200   4542b6ab34af   21 seconds ago       1.01GB
    <none>                                    <none>                                        1cdae087a970   About a minute ago   1.38GB

Depois de remover as imagens pendentes, o comando `docker image ls` mostra o seguinte:

    REPOSITORY                                TAG                                           IMAGE ID       CREATED              SIZE
    mid                                       trackdiscocopper-10-09-2020_10-14-2021_2200   4542b6ab34af   About a minute ago   1.01GB

## Iniciar MID Server em contêiner {#ariaid-title2}

O MID Server em contêiner usa uma imagem do Docker do MID Server que permite implantar MID Servers rapidamente. Os MID Servers são implantados usando ferramentas de orquestração como Docker Swarm.

### Antes de Iniciar

Função necessária: administrador

Pré-requisitos:

* Os hosts do Linux devem usar a arquitetura de distribuição do AlmaLinux de 64 bits e a distribuição do AlmaLinux é recomendada.

* O host deve usar o [mecanismo Docker e a interface de linha de comando (CLI) 20.10.4 ou posterior](https://docs.microsoft.com/en-us/virtualization/windowscontainers/quick-start/set-up-environment?tabs=Windows-Server).

  Nota:  
  Verifique a disponibilidade do docker executando o comando de versão do docker como administrador. Consulte a [documentação do comando de versão do docker](https://docs.docker.com/engine/reference/commandline/version/) para obter mais informações.
{#mid-launch-containerized__ul_pz4_td1_ypb}

### Procedimento

1. Quando a imagem estiver disponível, inicie o novo MID Server usando o comando docker run e especifique um arquivo env ou opções de variável env: docker run --env-file \<env_file_name_here\> \<docker_tag or image_id\>  
   Nota:  
   Não transmita dados confidenciais usando este comando, pois pode haver vulnerabilidades de segurança. Para transmitir dados confidenciais, use os procedimentos [Transmitir dados confidenciais para um MID Server em contêiner com Docker Secrets](https://servicenow-prod.fluidtopics.net/w8EAEeaECR6nAu8nJRH_ow#mid-containerized-sensitive-data "Você pode configurar MID Servers em contêiner com parâmetros de configuração passados por variáveis de ambiente ou arquivos secretos.") e [Transmitir dados confidenciais para um MID Server em contêiner com Kubernetes Secrets](https://servicenow-prod.fluidtopics.net/w8EAEeaECR6nAu8nJRH_ow#mid-containerized-kuber-secrets "Você pode configurar MID Servers em contêiner com parâmetros de configuração passados por variáveis de ambiente ou arquivos secretos.").

   Para obter mais informações, consulte as páginas de documentação do Docker para [o comando docker image ls](https://docs.docker.com/engine/reference/commandline/image_ls/), [o comando docker run](https://docs.docker.com/engine/reference/commandline/run/) e [a especificação de um arquivo env ou de opções de variável env](https://docs.docker.com/engine/reference/commandline/run/#set-environment-variables--e---env---env-file). O arquivo env é um arquivo de texto simples que usa o formato nome=valor. Se uma variável for especificada no arquivo env e na opção --env, a variável definida na linha de comando terá precedência.  
   Embora as solicitações de implantação sejam o método recomendado para iniciar MID Servers em contêiner, elas podem ser configuradas alternativamente com variáveis ambientais. Quando o contêiner for iniciado pela primeira vez, o script de inicialização usará as variáveis de ambiente e configurará a aplicação MID Server usando as seguintes variáveis de ambiente:

   MID_INSTANCE_URL
   :   Esta variável define o parâmetro de configuração "url".

   MID_INSTANCE_USERNAME
   :   Esta variável define o parâmetro de configuração "mid.instance.username".

   MID_INSTANCE_PASSWORD
   :   Esta variável define o parâmetro de configuração "mid.instance.password".

   MID_SERVER_NAME
   :   Esta variável define o parâmetro de configuração "name".

   MID_PROXY_HOST
   :   Esta variável define o parâmetro de configuração "mid.proxy.host". Esta variável não é obrigatória e só é necessária quando um proxy é configurado.

   MID_PROXY_PORT
   :   Esta variável define o parâmetro de configuração "mid.proxy.port".

   MID_PROXY_USERNAME
   :   Esta variável define o parâmetro de configuração "mid.proxy.username".

   MID_PROXY_PASSWORD
   :   Esta variável define o parâmetro de configuração "mid.proxy.password".

   MID_SECRETS_FILE
   :   Esta variável especifica o nome do arquivo secreto completo que contém dados confidenciais, como senhas ou certificado.

   MID_MUTUAL_AUTH_PEM_FILE
   :   Esta variável especifica o nome do arquivo completo do arquivo de certificado do cliente usado para configuração de validação automática.
2. **Opcional:** Para consultar uma lista de contêineres, execute o comando docker container ls: docker container ls \[-a\]

## Transmitir dados confidenciais para um MID Server em contêiner com Docker Secrets {#ariaid-title3}

Você pode configurar MID Servers em contêiner com parâmetros de configuração passados por variáveis de ambiente ou arquivos secretos.

### Antes de Iniciar

Função necessária: administrador Docker Swarm

### Por Que e Quando Desempenhar Esta Tarefa

Você pode passar dados confidenciais, como senhas ou certificados, para um MID Server em contêiner usando o [Docker Secret](https://docs.docker.com/engine/swarm/secrets/). Configure e inicie o [Docker Swarm](https://docs.docker.com/engine/swarm/) antes de usar este procedimento.

Ao criar implantações, certifique-se de que as réplicas sejam mantidas em 1.

### Procedimento

1. Inclua os dados confidenciais em mid-secrets.properties
2. Crie um segredo do Docker usando o comando docker secret create: docker secret create mid-secrets mid-secrets.properties  
   O primeiro mid-secrets representa o segredo no docker swarm, enquanto o segundo parâmetro mid-secrets.properties representa o caminho do arquivo para ler o segredo no sistema de arquivos da máquina host. Você pode listar todos os segredos criados executando o comando docker secret ls.

   Para obter mais informações sobre o comando docker secret, consulte a [documentação do docker secret](https://docs.docker.com/engine/reference/commandline/secret_create/).
3. Atualize a variável de ambiente MID_SECRETS_FILE com o caminho para o arquivo secreto dentro do contêiner.  
   O caminho padrão para os segredos do Docker Swarm no Linux é /run/secrets/mid-secrets.properties.
4. Implante o contêiner de imagem do MID Server no Swarm usando o comando docker service create: docker service create --name mid-service --secret mid-secrets.properties --env-file mid.env \<docker-tag or image-id\>  
   Certifique-se de que o sinalizador --secret seja fornecido para que o serviço de contêiner seja associado aos segredos especificados.

## Transmitir dados confidenciais para uma autenticação mútua do MID Server em contêiner com Docker Secrets {#ariaid-title4}

Você pode configurar MID Servers em contêiner com parâmetros de configuração passados por variáveis de ambiente ou arquivos secretos.

### Antes de Iniciar

Função necessária: administrador

Função necessária: administrador Docker Swarm

### Por Que e Quando Desempenhar Esta Tarefa

Se [a autenticação baseada em certificado](https://www.servicenow.com/docs/access?context=set-up-mutual-auth&version=yokohama&pubname=yokohama-platform-security&ft:locale=en-US) estiver habilitada na instância , o MID Server poderá ser configurado para [validar automaticamente usando um certificado de cliente de autenticação mútua](https://servicenow-prod.fluidtopics.net/bPTgDEAyJOGO0Z~jhS~zHg "Configure o MID Server para usar um certificado de cliente para autenticação na instância. Isso evita a necessidade de criar credenciais de autenticação básica no armazenamento de chaves para a configuração do MID Server.") (arquivo PEM). Isso pode ser feito definindo o caminho completo para o arquivo de certificado PEM dentro do contêiner com a variável de ambiente <var class="keyword varname">MID_MUTUAL_AUTH_PEM_FILE</var>. Por exemplo, você pode atualizar a variável para <var class="keyword varname">MID_MUTUAL_AUTH_PEM_FILE= /run/secrets/certificate.pem</var> no arquivo mid.env.

Você pode passar o arquivo de certificado PEM para um contêiner usando o Docker ou o segredo do Kubernetes. A seguir está um exemplo de comando para passar o arquivo de certificado PEM para um contêiner: docker service create --name mid-service --secret mid-secrets.properties --secret \<certificate-secret-name\> --env-file mid.env \<docker-tag or image-id\>

O certificado PEM mútuo é instalado no MID Server durante a inicialização. O MID Server se conecta à instância e é validado automaticamente. Quando o MID Server se conecta à instância com a autenticação mútua habilitada com sucesso, você pode observar algumas das seguintes entradas no registro do agente do MID:

* Certificado personalizado instalado no armazenamento de chaves do MID
* MID configurado para usar autenticação mútua
{#mid-containerized-mut-auth-sensi__ul_c2r_zv1_ypb}

### Procedimento

1. Prepare o pacote PEM de autenticação mútua.
2. Crie um segredo do Docker usando o comando docker secret create: `docker secret create mutual-auth-secret <mutual-auth-pem-file-on-local-filesystem> .`  
   Você pode listar todos os segredos criados executando o comando `docker secret ls`.
3. Atualize a variável de ambiente MID_MUTUAL_AUTH_PEM_FILE com o caminho para o arquivo secreto dentro do contêiner.  
   O caminho padrão para os segredos do Docker Swarm no Linux é /run/secrets/\<mutual-auth-pem-file-name\>.
4. Implante o contêiner de imagem do MID Server no Swarm usando o comando docker service create: d`ocker service create --name mid-service --secret mutual-auth-secret --env-file mid.env <docker-tag or image-id>`  
   Certifique-se de que o sinalizador `--secret` seja fornecido para que o serviço de contêiner seja associado aos segredos especificados.
5. Implante o MID Server em contêiner no pod com deployment.yml e execute o comando: `kubectl create -f deployment.yml`
{#mid-containerized-mut-auth-sensi__steps_yxn_zz1_zsb}

## Transmitir dados confidenciais para um MID Server em contêiner com Kubernetes Secrets {#ariaid-title5}

Você pode configurar MID Servers em contêiner com parâmetros de configuração passados por variáveis de ambiente ou arquivos secretos.

### Antes de Iniciar

Função necessária: administrador Kubernetest

Configure e inicie o [cluster Kubernetest](https://kubernetes.io/docs/setup/) antes de usar este procedimento. Para obter mais informações sobre Kubernetes Secrets, consulte a [documentação de Kubernetes Secrets](https://kubernetes.io/docs/concepts/configuration/secret/).  
Nota:  
O Kubernetes não funciona diretamente com uma imagem local. Carregue a imagem do MID Server em um registro público ou configure um registro local. Consulte [as instruções oficiais do Docker](https://docs.docker.com/registry/) sobre como criar um registro do Docker.

Ao criar implantações, certifique-se de que as réplicas sejam mantidas em 1.

### Procedimento

1. Inclua os dados confidenciais em mid-secrets.properties.
2. Crie um segredo do Kubernetes com o comando: kubectl create secret generic mid-secret --from-file=mid-secrets.properties
3. **Opcional:** Você pode listar todos os segredos criados executando o comando: kubectl get secrets
4. Atualize a variável de ambiente MID_SECRETS_FILE com o caminho para o arquivo secreto dentro do contêiner.  
   O caminho é definido no [campo de dados ao criar um arquivo de configuração para um segredo](https://kubernetes.io/docs/concepts/configuration/secret/).
5. Crie uma implantação com o seguinte exemplo de conteúdo YML :  

       apiVersion: apps/v1
       kind: Deployment
       metadata:
         name: basic-example
       spec:
         selector:
           matchLabels:
             app: MIDServerManagement
             provider: ServiceNow
         replicas: 1
         template:
           metadata:
             labels:
               app: MIDServerManagement
               provider: ServiceNow
           spec:
             containers:
               - name: basic-example-container
                 imagePullPolicy: IfNotPresent
                 image: "mid:imageTag"
                 env:
                   - name: MID_INSTANCE_URL
                     value: " https://exampleinstance.service-now.com/"
                   - name: MID_INSTANCE_USERNAME
                     value: "mid_server_user_name"
                   - name: MID_SECRETS_FILE
                     value: "/opt/snc_mid_server/secrets/mid-secrets.properties"
                   - name: MID_SERVER_NAME
                     value: "Basic-Example-MID"
                 volumeMounts:
                   - mountPath: "/opt/snc_mid_server/secrets"
                     name: "mid-mount-secret"
                     readOnly: true
             volumes:
             - name: "mid-mount-secret"
               secret:
                 secretName: "mid-secret"

   Nota:  
   Há muitas maneiras de criar uma implantação ou pod. Para obter mais informações, consulte as [instruções de implantação do Kubernetes](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/).
6. Implante o MID Server em contêiner no pod com deployment.yml e execute o comando: kubectl create -f deployment.yml

## Transmitir dados confidenciais para uma autenticação mútua do MID Server em contêiner com Kubernetes Secrets {#ariaid-title6}

Você pode configurar MID Servers em contêiner com parâmetros de configuração passados por variáveis de ambiente ou arquivos secretos.

### Antes de Iniciar

Função necessária: administrador Kubernetest

Pré-requisitos:

Se [a autenticação baseada em certificado](https://www.servicenow.com/docs/access?context=set-up-mutual-auth&version=yokohama&pubname=yokohama-platform-security&ft:locale=en-US) estiver habilitada na instância , o MID Server poderá ser configurado para [validar automaticamente usando um certificado de cliente de autenticação mútua](https://servicenow-prod.fluidtopics.net/bPTgDEAyJOGO0Z~jhS~zHg "Configure o MID Server para usar um certificado de cliente para autenticação na instância. Isso evita a necessidade de criar credenciais de autenticação básica no armazenamento de chaves para a configuração do MID Server.") (arquivo PEM). Isso pode ser feito definindo o caminho completo para o arquivo de certificado PEM dentro do contêiner com a variável de ambiente <var class="keyword varname">MID_MUTUAL_AUTH_PEM_FILE</var>. Você pode passar o arquivo de certificado PEM para um contêiner usando o segredo do Kubernetes.

O certificado PEM mútuo é instalado no MID Server durante a inicialização. O MID Server se conecta à instância e é validado automaticamente. Quando o MID Server se conecta à instância com a autenticação mútua habilitada com sucesso, você pode observar algumas das seguintes entradas no registro do agente do MID:

* Certificado personalizado instalado no armazenamento de chaves do MID
* MID configurado para usar autenticação mútua
{#mid-containerized-mut-auth-kuber__ul_c2r_zv1_ypb}

### Procedimento

1. Prepare o pacote PEM de autenticação mútua.
2. Crie um segredo do Kubernetes com o comando: `kubectl create secret generic mutual-auth-secret --from-file=<mutual-auth-pem-file>`
3. **Opcional:** Você pode verificar todos os segredos criados executando o comando: `kubectl get secrets`
4. Atualize a variável de ambiente MID_MUTUAL_AUTH_PEM_FILE com o caminho para o arquivo secreto dentro do contêiner.
5. Crie uma implantação com o seguinte exemplo de conteúdo YML:  

       6.	apiVersion: apps/v1
       7.	kind: Deployment
       8.	metadata:
       9.	  name: mutual-auth-example
       10.	spec:
       11.	  selector:
       12.	    matchLabels:
       13.	      app: MIDServerManagement
       14.	      provider: ServiceNow
       15.	  replicas: 1
       16.	  template:
       17.	    metadata:
       18.	      labels:
       19.	        app: MIDServerManagement
       20.	        provider: ServiceNow
       21.	    spec:
       22.	      containers:
       23.	        - name: mutual-auth -container
       24.	          imagePullPolicy: IfNotPresent
       25.	          image: "mid:imageTag"
       26.	          env:
       27.	            - name: MID_INSTANCE_URL
       28.	              value: "https://exampleinstance.service-now.com/"
       29.	            - name: MID_INSTANCE_USERNAME
       30.	              value: "mid_server_user_name"
       31.	            - name: MID_SERVER_NAME
       32.	              value: "Mutual-Auth-Deployment-MID"
       33.	            - name: MID_MUTUAL_AUTH_PEM_FILE
       34.	              value: "/opt/snc_mid_server/mutual-auth/yourpemfile.pem"
       35.	          volumeMounts:
       36.	            - mountPath: "/opt/snc_mid_server/mutual-auth"
       37.	              name: "mid-mount-mutual-auth"
       38.	              readOnly: true
       39.	      volumes:
       40.	      - name: "mid-mount-mutual-auth"
       41.	        secret:
       42.	          secretName: "mid-mutual-auth-secret"

6. Implante o MID Server em contêiner no pod com deployment.yml e execute o comando: `kubectl create -f deployment.yml`

