Tengo un servidor de nodo v6.10.0 en mi macOS que se inicia automáticamente desde el CMD en Dockerfile . Normalmente, en mi entorno de desarrollo local sin contenedores, usaré CTRL+C para eliminar el servidor. Al no poder (o no saber) hacer esto en el contenedor, recurro a ps aux | grep node para intentar eliminar manualmente los procesos. Entonces, obtengo algo como esto:
myapp [master] :> kubectl exec -it web-3127363242-xb50k bash root@web-3127363242-xb50k:/usr/src/app# ps aux | grep node root 15 0.4 0.9 883000 35804 ? Sl 05:49 0:00 node /usr/src/app/node_modules/.bin/concurrent --kill-others npm run start-prod npm run start-prod-api root 43 0.1 0.6 743636 25240 ? Sl 05:49 0:00 node /usr/src/app/node_modules/.bin/better-npm-run start-prod root 44 0.1 0.6 743636 25140 ? Sl 05:49 0:00 node /usr/src/app/node_modules/.bin/better-npm-run start-prod-api root 55 0.0 0.0 4356 740 ? S 05:49 0:00 sh -c node ./bin/server.js root 56 0.0 0.0 4356 820 ? S 05:49 0:00 sh -c node ./bin/api.js root 57 18.6 4.9 1018088 189416 ? Sl 05:49 0:08 node ./bin/server.js root 58 13.9 5.2 1343296 197576 ? Sl 05:49 0:06 node ./bin/api.js root 77 0.0 0.0 11128 1024 ? S+ 05:50 0:00 grep nodeCuando trato de matar a uno de ellos por
kill -9 15 Me sacan del caparazón de mi contenedor y me devuelven al caparazón de mi computadora. Cuando vuelvo a ingresar al contenedor, veo que el proceso todavía está allí con la misma identificación de proceso. Este ejemplo usa un pod de Kubernetes pero creo que tengo el mismo resultado al ingresar un contenedor Docker usando el comando docker exec .
Cada contenedor acoplable tiene un PUNTO DE ENTRADA que se establecerá en el archivo acoplable , mediante declaraciones ENTRYPOINT o CMD , o se especificará en el comando de ejecución docker run myimage:tag "entrypoint_command" . Cuando se elimina el proceso ENTRYPOINT , creo que también se elimina el contenedor. El docker exec , tal como lo entiendo, es como un comando de "adjuntar" a un contenedor. Pero si el PUNTO DE ENTRADA no funciona, no hay ningún contenedor al que conectarse.
Kubernetes reiniciará un contenedor después de una falla, según tengo entendido. Que podría ser la razón por la que ves que el proceso está de vuelta. Realmente no he trabajado con Kubernetes, pero intentaría jugar con la forma en que se escalan las replicaciones para terminar su proceso.
Los contenedores aíslan su aplicación deseada como pid 1 dentro del espacio de nombres. La aplicación deseada es su punto de entrada o cmd si no tiene un punto de entrada definido. Si la eliminación de un proceso da como resultado la salida del pid 1, el contenedor se detendrá de inmediato (similar a eliminar el pid 1 en un host de Linux) junto con la eliminación de todos los demás pid. Si este contenedor tiene una política de reinicio, se reiniciará y los procesos obtendrán los mismos pid que la última vez que se ejecutaron (en igualdad de condiciones, lo que a menudo se encuentra dentro de un contenedor).
Para evitar que el contenedor se detenga, deberá ajustar su punto de entrada para que permanezca activo incluso si se elimina el proceso secundario. Por ese lado, hacer que el contenedor salga suele ser un comportamiento preferido para manejar errores inesperados al volver a un estado limpio.