Instalar el administrador de trabajos Sintético

Nuestros administradores de trabajos de monitoreo de Sintético son recursos basados en contenedoresDocker que aceptan y ejecutan monitores de Sintético asignados a la ubicación privada.

El administrador de trabajos puede operar en un entorno de sistema contenedor Docker , un entorno de sistema contenedor Podman o un entorno de sistema de orquestación contenedor Kubernetes . El administrador de trabajos detectará automáticamente su entorno para seleccionar el modo operativo apropiado.

Característica del gestor de trabajo sintético

Debido a que el administrador de trabajos de Sintético opera como un contenedor en lugar de una máquina virtual, hemos simplificado la instalación, la introducción y la actualización de la administración y orquestación de trabajos. También viene con algunas funciones adicionales:

Compatible con Linux, macOS y Windows.
Seguridad mejorada y soporte para la ejecución de usuarios no root .
Capacidad de aprovechar un contenedor Docker como entorno sandbox .

Característica específica de Kubernetes

El administrador de trabajos introduce algunas funciones adicionales específicas de Kubernetes:

Utiliza recursos de Kubernetes CronJob para ejecutar un monitor sin ping
No requiere acceso privilegiado al socket de la docker
Soporta clúster de Kubernetes alojado y on-premise
Admite varios motores de contenedores como Docker y Containerd
Implementable a través de gráficos Helm y YAML de configuración
Permite la asignación de recursos basada en el tiempo de ejecución del trabajo configurable (ping, API y browser) para una gestión óptima de los recursos.
Observabilidad ofrecida a través del explorador New Relic clúster de Kubernetes

requisito del sistema y compatibilidad

Para alojar administradores de trabajos de Sintético, su sistema debe cumplir con los requisitos mínimos para el entorno del sistema elegido.

Advertencia

No modifique ningún archivo del administrador de trabajos de Sintético. New Relic no es responsable de las modificaciones que realice. Para obtener más información, comuníquese con su representante de cuenta o con un representante técnico de ventas de New Relic.

Compatibilidad para	Requisitos
Sistema operativo	Linux kernel: 3.10 o superior macOS: 10.11 o superior Windows: Windows 10 de 64 bits o superior También debe configurar docker para ejecutar el contenedor de Linux para que los administradores de trabajos de Sintético funcionen en sistemas Windows.
Procesador	Una CPU AMD64 o x86_64 moderna y multinúcleo
Memoria	3.256 GiB de RAM por núcleo de CPU (dedicado)
Tamaño del disco	Un mínimo de 50 GiB por host
sistema de archivos de disco	NFSv4.1 o superior (si usa NFS)
Versión Docker	Docker 17.12.1-ce o mas alto
Clave de ubicación privada	Debes tener una clave de ubicación privada

Advertencia

El administrador de trabajos Docker Sintéticos no está diseñado para usar con orquestadores de contenedores como AWS ECS, Docker Swarm, Apache Mesos, Azure contenedor instancia, etc. Ejecutar el administrador de trabajos Docker Sintéticos en un orquestador de contenedores genera problemas inesperados, ya que funciona como un orquestador en sí mismo. Si está empleando la orquestación de contenedor, consulte nuestros requisitos del administrador de trabajosKubernetes Sintéticos.

Compatibilidad para	Requisitos
Sistema operativo	Linux kernel: 3.10 o superior
Procesador	Una CPU AMD64 o x86_64 moderna y multinúcleo
Memoria	3.256 GiB de RAM por núcleo de CPU (dedicado)
Tamaño del disco	Un mínimo de 50 GiB por host
sistema de archivos de disco	NFSv4.1 o superior (si usa NFS)
Versión de Podman	Podman 5.0.0-ce o superior
Clave de ubicación privada	Debes tener una clave de ubicación privada

Advertencia

El administrador de trabajos Podman Sintéticos no está diseñado para usar con orquestadores de contenedores como AWS ECS, Docker Swarm, Apache Mesos, Azure contenedor instancia, etc. Ejecutar el administrador de trabajos Docker Sintéticos en un orquestador de contenedores genera problemas inesperados, ya que funciona como un orquestador en sí mismo. Si está empleando la orquestación de contenedor, consulte nuestros requisitos del administrador de trabajosKubernetes Sintéticos.

Compatibilidad para	Requisitos
Sistema operativo	Linux kernel: 3.10 o superior macOS: 10.11 o superior El contenedor de Linux, incluido el administrador de trabajos, solo se ejecuta en nodos Linux K8.
Procesador	Una CPU moderna y multinúcleo
Podde gestión de trabajos Sintético	CPU (vCPU/Core): 0,5 hasta 0,75 Memory: 800Mi hasta 1600Mi Los recursos asignados a un pod de administrador de trabajos de Sintético son configurables por el usuario.
Podde tiempo de ejecución de ping	CPU (vCPU/Core): 0,5 hasta 0,75 Memory: 500Mi hasta 1Gi Consideraciones adicionales: Los recursos asignados a un pod de tiempo de ejecución de ping son configurables por el usuario. La relación máxima de recursos de solicitud de límite tanto para la CPU como para la memoria es 2.
Podde tiempo de ejecución de API de Node.js	CPU (vCPU/Core): 0,5 hasta 0,75 Memory: 1250Mi hasta 2500Mi Consideraciones adicionales: Los recursos asignados a un pod de tiempo de ejecución de API de Node.js son configurables por el usuario. La relación máxima de recursos de solicitud de límite tanto para la CPU como para la memoria es 2.
Runtime de ejecución Node.js browser pod	CPU (vCPU/Core): 1,0 hasta 1,5 Memory: 2000Mi hasta 3000Mi Consideraciones adicionales: Los recursos asignados a un pod de tiempo de ejecución browser Node.js son configurables por el usuario. La relación máxima de recursos de solicitud de límite tanto para la CPU como para la memoria es 2.
Tamaño del disco	Root volume: Un mínimo de 50 GiB
sistema de archivos de disco	NFSv4.1 o superior (si usa NFS)
Versión Kubernetes	Se requiere Kubernetes v1.21 o posterior.
Clave de ubicación privada	Debes tener una clave de ubicación privada
Timón	Siga las instrucciones de instalación de Helm v3 para su sistema operativo.
Kubectl	Siga las instrucciones de instalación de Kubectl para su sistema operativo.

Para ver las versiones, dependencias, valores predeterminados de cuántos pods de tiempo de ejecución se inician con cada administrador de trabajos de Sintético y más, consulte Mostrar ayuda y ejemplos a continuación.

Clave de ubicación privada

Antes de lanzar los gestores de trabajos de Sintético, debes tener una clave de ubicación privada. Su administrador de trabajos de Sintético usa la clave para autenticarse en New Relic y ejecutar el monitor asociado con esa ubicación privada.

Para encontrar la clave de una ubicación privada existente:

Vaya a one.newrelic.com > Synthetic monitoring > Private locations.
En el índice Private locations , localice la ubicación privada a la que desea que se asigne su administrador de trabajos de Sintético.
Tenga en cuenta la clave asociada a la ubicación privada con la clave icono.

Instalar, actualizar y configurar el administrador de trabajos Sintético

Si está ejecutando más de un contenedor de ubicación privada Docker o Podman en el mismo host, tendrá conflictos de puertos. Para evitar esta contención de puertos, cerciorar de hacer lo siguiente cuando comience a configurar administradores de trabajos:

Ejecute administradores de trabajos y llamadas por minuto en diferentes hosts.
Ejecute cada administrador de trabajos en un host independiente.
Ejecute cada llamada por minuto en un host diferente.

Las imágenes del administrador de trabajos de Sintético están alojadas en Docker Hub. Vaya a hub.docker.com/r/newrelic/synthetics-job-manager/tags para obtener una lista de todos los lanzamientos.

A menos que esté alojando las imágenes en un repositorio de imágenes local, debe permitir conexiones a docker.io a través de su firewall para que Docker o Podman puedan extraer el trabajo del administrador de imágenes sintéticas y el tiempo de ejecución de las imágenes sintéticas. Cuando se inicia el administrador de trabajos de Sintéticos, las imágenes en tiempo de ejecución se extraen automáticamente. Consulte Configuración del entornoDocker , Configuración del entorno Podman y Configuración del entornoKubernetes para obtener detalles sobre cómo configurar un repositorio local y el extremo del registro del corredor.

Para obtener más detalles sobre la configuración avanzada, consulte Configuración del administrador de trabajos de Sintético.

Iniciar gestor de trabajos Sintético

A continuación se muestran las instrucciones aplicables de Docker, Podman o Kubernetes para iniciar el administrador de trabajos.

Localice su clave de ubicación privada.
Cerciorar de habilitar la dependenciaDocker para el sandbox y de instalar el administrador de trabajos Sintéticos en su sistema.
Ejecute el script apropiado para su sistema. Adapte el valor predeterminado común /var/run/docker.sock en los siguientes ejemplos para que coincida con su sistema.
- Linux/macOS:
  bash
```
$docker run \
>    --name YOUR_CONTAINER_NAME \
>    -e "PRIVATE_LOCATION_KEY=YOUR_PRIVATE_LOCATION_KEY" \
>    -v /var/run/docker.sock:/var/run/docker.sock:rw \
>    -d \
>    --restart unless-stopped \
>    newrelic/synthetics-job-manager:latest
```
- Ventanas:
  bash
```
$docker run ^
$    --name YOUR_CONTAINER_NAME ^
$    -e "PRIVATE_LOCATION_KEY=YOUR_PRIVATE_LOCATION_KEY" ^
$    -v /var/run/docker.sock:/var/run/docker.sock:rw ^
$    -d ^
$    --restart unless-stopped ^
$    newrelic/synthetics-job-manager:latest
```
Vea el registro de su contenedor minion:
bash
```
$docker logs --follow YOUR_CONTAINER_NAME
```

Localice su clave de ubicación privada.
Cerciorar de habilitar la dependencia de Podman para el sandbox y de instalar el administrador de trabajos Sintéticos en su sistema.
Ejecute el siguiente script para su sistema.
Para crear un pod en Linux y agregar la dirección IP de la máquina host:
```
podman pod create --network slirp4netns --name YOUR_POD_NAME --add-host=podman.service:IP_ADDRESS
```
Para iniciar el Administrador de trabajos:
```
podman run \
--name YOUR_CONTAINER_NAME \
--pod YOUR_POD_NAME \
-e "PRIVATE_LOCATION_KEY=YOUR_PRIVATE_LOCATION_KEY" \
-e "CONTAINER_ENGINE=PODMAN" \
-e "PODMAN_API_SERVICE_PORT=YOUR_PODMAN_API_SERVICE_PORT" \
-e "PODMAN_POD_NAME=YOUR_POD_NAME" \
-d \
--restart unless-stopped \
newrelic/synthetics-job-manager:latest
```
Para ver los logs de su minion contenedor:
```
podman logs --follow YOUR_CONTAINER_NAME
```

Localice su clave de ubicación privada.
Configure un namespace para el administrador de trabajos de Sintético en su clúster de Kubernetes:
bash
```
$kubectl create namespace YOUR_NAMESPACE
```
Copie los gráficos de Helm del repositorio de New Relic Helm.
- Si está copiando los gráficos por primera vez:
  bash
```
$helm repo add YOUR_REPO_NAME https://helm-charts.newrelic.com
```
- Si anteriormente copió los gráficos de Helm del repositorio de New Relic Helm, obtenga lo último:
  bash
```
$helm repo update
```

Instale el administrador de trabajos Sintético con el siguiente comando de Helm:

Para una nueva instalación del administrador de trabajos Sintético:

helm install YOUR_JOB_MANAGER_NAME YOUR_REPO_NAME/synthetics-job-manager -n YOUR_NAMESPACE --set synthetics.privateLocationKey=YOUR_PRIVATE_LOCATION_KEY

Para actualizar una instalación existente del administrador de trabajos de Sintético:

bash

$helm upgrade YOUR_JOB_MANAGER_NAME YOUR_REPO_NAME/synthetics-job-manager -n YOUR_NAMESPACE --set synthetics.privateLocationKey=YOUR_PRIVATE_LOCATION_KEY

Compruebe si el pod del administrador de trabajos de Sintético está en funcionamiento:
bash
```
$kubectl get -n YOUR_NAMESPACE pods
```
Una vez que el atributo status de cada pod se muestra como running, su administrador de trabajos de Sintético estará activo y listo para ejecutar el monitor asignado a su ubicación privada.

Detener o eliminar el administrador de trabajos de Sintético

En un entorno de sistema contenedor Docker o Podman, emplee el procedimiento stop respectivo para detener el administrador de trabajos Sintéticos. En un entorno de sistema de orquestación de contenedores Kubernetes , emplee el procedimiento Kubernetes delete para detener la ejecución del administrador de trabajos sintéticos.

Puede detener un contenedor Docker por el nombre del contenedor o por el ID del contenedor.

Detención del nombre del contenedor para Linux, macOS y Windows:
bash
```
$docker stop YOUR_CONTAINER_NAME
$docker rm YOUR_CONTAINER_NAME
```
Detención de ID de contenedor para Linux/macOS:
En los ejemplos, el contenedor se detiene y se retira. Para detener únicamente el contenedor, omita docker rm $CONTAINER_ID.
bash
```
$CONTAINER_ID=$(docker ps -aqf name=YOUR_CONTAINER_NAME)
$docker stop $CONTAINER_ID
$docker rm $CONTAINER_ID
```
Detención de ID de contenedor para Windows:
En los ejemplos, el contenedor se detiene y se retira. Para detener únicamente el contenedor, omita docker rm $CONTAINER_ID.
bash
```
$FOR /F "tokens=*" %%CID IN ('docker ps -aqf name=YOUR_CONTAINER_NAME') do (SET CONTAINER_ID=%%CID)
$docker stop %CONTAINER_ID%
$docker rm %CONTAINER_ID%
```

Puede detener un contenedor Podman por el nombre del contenedor o por el ID del contenedor.

Nombre del contenedor stop para Linux:

podman stop YOUR_CONTAINER_NAME
podman rm YOUR_CONTAINER_NAME

Detención del ID del contenedor para Linux:
En los ejemplos, el contenedor se detiene y se retira. Para detener únicamente el contenedor, omita podman rm $CONTAINER_ID.
```
CONTAINER_ID=$(podman ps -aqf name=YOUR_CONTAINER_NAME)
podman stop $CONTAINER_ID
podman rm $CONTAINER_ID
```

Obtenga el JOB_MANAGER_POD_INSTALLATION_NAME del pod del administrador de trabajos de Sintético que desea eliminar:
bash
```
$helm list -n YOUR_NAMESPACE
```

Eliminar el minion pod:

bash

$helm uninstall -n YOUR_NAMESPACE JOB_MANAGER_POD_INSTALLATION_NAME

Elimina el namespace configurado para el administrador de trabajos de Sintético en tu clúster de Kubernetes:
bash
```
$kubectl delete namespace YOUR_NAMESPACE
```

Sandboxing y dependencia

El sandboxing y la dependencia son aplicables al gestor de trabajos Sintéticos en un entorno de sistema contenedor Docker o Podman.

El administrador de trabajos de Sintético se ejecuta en docker y puede aprovechar docker como tecnología de espacio aislado. Esto garantiza un aislamiento completo de la ejecución del monitor, lo que mejora la seguridad, la confiabilidad y la repetibilidad. Cada vez que se ejecuta un monitor browser o script, el administrador de trabajos de Sintético crea un nuevo contenedor docker para ejecutarlo utilizando el tiempo de ejecución correspondiente.

El contenedor del administrador de trabajos Sintético debe configurarse para comunicarse con el motor docker a fin de generar contenedores de tiempo de ejecución adicionales. Luego, cada contenedor generado se dedica a ejecutar una verificación asociada con el monitor Sintético que se ejecuta en la ubicación privada a la que está asociado el contenedor del administrador de trabajos Sintético.

Existe una dependencia crucial en el lanzamiento. Para habilitar el espacio aislado, asegúrese de que:

Su socket UNIX docker grabable está montado en la variable de entorno /var/run/docker.sock o DOCKER_HOST. Para obtener más información, consulte Opción de socket Daemon de Docker.
Advertencia
El recuento de núcleos en el host determina cuántos contenedores de tiempo de ejecución puede ejecutar el administrador de trabajos Sintético simultáneamente en el host. Dado que los requisitos de memoria se ajustan al recuento esperado del contenedor de tiempo de ejecución, recomendamos not running multiple synthetics job managers on the same host para evitar la contención de recursos.
Para obtener información adicional sobre el sandboxing y la ejecución como usuario raíz o no root, consulte Seguridad, sandboxing y ejecución como no root.

El administrador de trabajos Sintéticos se ejecuta en Podman y puede aprovechar Podman como una tecnología de sandbox. Esto garantiza un aislamiento completo de la ejecución del monitor, lo que mejora la seguridad, la confiabilidad y la repetibilidad. Cada vez que se ejecuta un monitor browser o script, el administrador de trabajos de Sintéticos crea un nuevo contenedor Podman para ejecutarlo empleando el entorno de ejecución correspondiente.

El administrador de trabajos Sintéticos contenedor debe configurar para comunicar con el motor Podman a fin de generar tiempo de ejecución adicional contenedor. Luego, cada contenedor generado se dedica a ejecutar una verificación asociada con el monitor Sintético que se ejecuta en la ubicación privada con la que está asociado el contenedor del administrador de trabajos Sintéticos.

Existe una dependencia crucial en el lanzamiento. Para habilitar el sandboxing, cerciorar de tener:

Instaló Podman 5.0.0-ce o superior.
Habilitada la ejecución sin raíz:
- Configure Podman para ejecutar contenedor sin requerir privilegios de root.
  mkdir -p ~/.config/containers touch ~/.config/containers/containers.conf vi ~/.config/containers/containers.conf
- Edite el archivo containers.conf para configurar Podman para que use crun y systemd:
  [engine] runtime = "crun" cgroup_manager = "systemd"
Se habilitaron los cgroups v2 (solo RHEL):
- Edite GRUB para habilitar cgroups v2, esto garantiza la compatibilidad con los tiempos de ejecución de contenedor modernos en RHEL.
  sudo sed -i 's/GRUB_CMDLINE_LINUX="/&systemd.unified_cgroup_hierarchy=1 /' /etc/default/grub sudo grub2-mkconfig -o /boot/grub2/grub.cfg sudo reboot

Se habilitó la delegación en todo el sistema para permitir la delegación cgroups para los servicios de Podman.

sudo mkdir -p /etc/systemd/system/user@.service.d/
echo -e "[Service]\nDelegate=yes" | sudo tee /etc/systemd/system/user@.service.d/delegate.conf > /dev/null

Configurar el servicio de nivel de usuario systemd :
- Crear directorios para los servicios de nivel de usuario systemd .
  mkdir -p ~/.config/systemd/user/podman.service.d
- Agregue la configuración de delegado al servicio de nivel de usuario systemd .
  echo -e "[Service]\nDelegate=yes" > ~/.config/systemd/user/podman.service.d/override.conf

Habilitado e iniciado el socket Podman.

systemctl --user enable podman.socket
systemctl --user start podman.socket
systemctl --user status podman.socket

Creó y configuró el servicio API de Podman:

Crea un servicio API de Podman y configura Podman para proporcionar acceso a la API HTTP.

mkdir -p ~/.config/systemd/user
touch ~/.config/systemd/user/podman-api.service
vi ~/.config/systemd/user/podman-api.service

Define el servicio para exponer la API de Podman en el puerto 8000.

[Unit]
Description=Podman API Service
After=default.target

[Service]
Type=simple
ExecStart=/usr/bin/podman system service -t 0 tcp:0.0.0.0:8000
Restart=on-failure

[Install]
WantedBy=default.target

Habilitado e iniciado el servicio API de Podman.
```
systemctl --user daemon-reload
systemctl --user enable podman-api.service
systemctl --user start podman-api.service
systemctl --user status podman-api.service
```
Advertencia
El recuento de núcleos en el host determina cuántos contenedores de tiempo de ejecución puede ejecutar el administrador de trabajos Sintético simultáneamente en el host. Dado que los requisitos de memoria se ajustan al recuento esperado del contenedor de tiempo de ejecución, recomendamos not running multiple synthetics job managers on the same host para evitar la contención de recursos.

Seguridad, espacio aislado y ejecución como no root

De forma predeterminada, el software que se ejecuta dentro de un administrador de trabajos de Sintético se ejecuta con root privilegios de usuario. Esto es adecuado para la mayoría de los escenarios, ya que la ejecución está protegida.

Para ejecutar el administrador de trabajos de Sintético como usuario no root, se requieren pasos adicionales:

Para obtener más información, consulte la documentación oficial de Docker sobre seguridad y perfiles de seguridad de AppArmor.

Si su entorno requiere que ejecute el administrador de trabajos de Sintético como usuario no root, siga este procedimiento. En el siguiente ejemplo, el usuario no root es my_user.

Asegúrese de que my_user pueda utilizar el motor Docker en el host:
Verifique que my_user pertenezca al grupo de sistemas "docker" . Aún se necesita acceso raíz con alcance a docker.sock para crear redes puente.
O
Habilite la opción de socket TCP de Docker y pase la variable de entorno DOCKER_HOST al administrador de trabajos de Sintético.
Verifique que my_user tenga permisos de lectura/escritura en todos los directorios y volúmenes pasados al administrador de trabajos de Sintético. Para establecer estos permisos, utilice el comando chmod .
Obtenga el uid de my_user para usarlo en el comando de ejecución: id -u my_user.
Una vez que se cumplan estas condiciones, utilice la opción "-u <uid>:<gid>" al iniciar el administrador de trabajos de Sintético:
bash
```
$docker run ... -u 1002 ...
```
O
bash
```
$docker run ... -u 1002 -e DOCKER_HOST=http://localhost:2375 ...
```

Comprenda sus entornos Docker, Podman o Kubernetes

A continuación se muestra información adicional sobre cómo mantener y comprender el entorno de contenedor del administrador de trabajos. Vea información de licencia, comprenda la configuración de red del administrador de trabajos y consulte el repositorio de imágenes docker .

Utilice estas opciones según corresponda:

Para realizar un seguimiento de los logs Docker o Podman y verificar el estado de sus monitores, consulte Mantenimiento y monitoreo del administrador de trabajos sintéticos.
Para un administrador de trabajos de Sintético en el entorno del sistema de orquestación de contenedores de Kubernetes, se pueden usar los siguientes comandos de Helm show para ver chart.yaml y values.yaml, respectivamente:
bash
```
$helm show chart YOUR_REPO_NAME/synthetics-job-manager
```
bash
```
$helm show values YOUR_REPO_NAME/synthetics-job-manager
```

Tanto para docker como para Kubernetes, el administrador de trabajos de Sintético y su contenedor de tiempo de ejecución heredarán la configuración de red del host. Para ver un ejemplo de esto en un entorno de sistema de contenedor docker , consulte el sitiodocker .

Se crea una red puente para la comunicación entre el administrador de trabajos de Sintético y el contenedor de tiempo de ejecución. Esto significa que las opciones de comando de red como --network y --dns que se pasan al contenedor del administrador de trabajos de Sintético en el momento del lanzamiento (como a través de comandos de ejecución docker en un entorno de sistema de contenedor docker ) no son heredadas ni utilizadas por los contenedores de tiempo de ejecución.

Cuando se crean estas redes, se extraen del grupo de direcciones IP predeterminado configurado para daemon. Para ver un ejemplo de esto en un entorno de sistema de contenedor Docker, consulte el sitio Docker .

En el caso de Podman, no empleamos una red de puente para la comunicación entre el administrador de trabajos Sintéticos y el contenedor en tiempo de ejecución, en su lugar usamos un pod Podman. Todos los contenedores en un pod Podman comparten el mismo namespace de red. Esto significa que comparten la misma dirección IP dentro de ese pod. En este caso aunque los contenedores comparten la misma IP, sus servicios están expuestos en puertos diferentes.

Consideraciones adicionales para la conexión del administrador de trabajos de Sintético

Conexión	Descripción
Gestores de empleo Sintético sin acceso a Internet	Un gestor de trabajos de Sintético puede operar sin acceso a Internet, pero con algunas excepciones. El gestor de trabajos de Sintético debe poder contactar con el dominio `"synthetics-horde.nr-data.net"` . Esto es necesario para que informe datos a New Relic y reciba un monitor para ejecutar. Pregunte a su administrador de red si esto representa un problema y cómo configurar excepciones.
Comunicarse con Sintético a través de un proxy	Para configurar la comunicación con New Relic mediante proxy, utilice las variables de entorno denominadas `HORDE_API_PROXY*.`
Argumentos aprobados en el lanzamiento	Esto se aplica únicamente al entorno contenedor Docker y Podman. Los argumentos que se pasan al administrador de trabajos Sintéticos contenedor en el lanzamiento no se pasan al contenedor en tiempo de ejecución generado por el administrador de trabajos Sintéticos. Docker y Podman no tienen el concepto de "herencia" o "jerarquía" de contenedor, y no copiamos la configuración que se pasa del administrador de trabajos sintéticos al contenedor en tiempo de ejecución. Sin embargo, en el caso de Podman, los argumentos que se pasan a nivel pod se comparten entre el administrador de trabajos de Sintéticos y el contenedor en tiempo de ejecución dentro del pod. La única configuración compartida entre ellos es la establecido en el nivel del demonio Docker .

Te ofrecemos esta traducción automática para facilitar la lectura.

Instalar el administrador de trabajos Sintético

Característica del gestor de trabajo sintético

Característica específica de Kubernetes

requisito del sistema y compatibilidad

Advertencia

Requisitos del entorno del sistema Docker Contenedor

Advertencia

Advertencia

Requisitos del entorno del sistema de orquestación de contenedores Kubernetes

Clave de ubicación privada

Instalar, actualizar y configurar el administrador de trabajos Sintético

Iniciar gestor de trabajos Sintético

Procedimiento de inicio de docker

Procedimiento de inicio de Kubernetes

Detener o eliminar el administrador de trabajos de Sintético

Procedimiento de detención de docker

Procedimiento de eliminación de Kubernetes

Sandboxing y dependencia

Dependencia de Docker

Advertencia

Advertencia

Seguridad, espacio aislado y ejecución como no root

Ejecutar como usuario no root para Docker

Comprenda sus entornos Docker, Podman o Kubernetes

Mantener el administrador de trabajos.

Mostrar información de licencia

Configuración de la red

Repositorio de imágenes Docker

Consideraciones adicionales para la conexión del administrador de trabajos de Sintético

Te ofrecemos esta traducción automática para facilitar la lectura.

Instalar el administrador de trabajos Sintético

Característica del gestor de trabajo sintético .css-21sua1{background:none;border:none;width:0;padding:0;}

Característica específica de Kubernetes

requisito del sistema y compatibilidad

Advertencia

Requisitos del entorno del sistema de orquestación de contenedores Kubernetes

Clave de ubicación privada

Instalar, actualizar y configurar el administrador de trabajos Sintético

Iniciar gestor de trabajos Sintético

Procedimiento de inicio de docker

Procedimiento de inicio de Kubernetes

Detener o eliminar el administrador de trabajos de Sintético

Procedimiento de detención de docker

Procedimiento de eliminación de Kubernetes

Sandboxing y dependencia

Dependencia de Docker

Seguridad, espacio aislado y ejecución como no root

Ejecutar como usuario no root para Docker

Comprenda sus entornos Docker, Podman o Kubernetes

Mantener el administrador de trabajos.

Mostrar información de licencia

Configuración de la red

Repositorio de imágenes Docker

Consideraciones adicionales para la conexión del administrador de trabajos de Sintético

Característica del gestor de trabajo sintético