Platzi
Platzi

¡Invierte en ti y celebremos! Adquiere un plan Expert o Expert+ a precio especial.

Antes: $349
$259
Currency
Antes: $349
Ahorras: $90
COMIENZA AHORA
Termina en: 15D : 9H : 3M : 5S

Debes tener cuenta en Platzi

Para ver esta clase abierta debes iniciar sesión

Implementación de Dockerfile3/21

En esta clase te vamos a mostrar cómo usar un Dockerfile y manejar las dependecias para tenerlas lock in, siempre instalar una versión que ya usaste y probaste.

FROM: Busco una imagen de origen y a partir de ahí se monta el container.
WORKDIR: Es recomendable no correr todo el root. Con esto le decimos a Docker cuál va a ser nuestra carpeta de trabajo.
ADD: Es donde indicamos nuestras dependencias como package.json, hace cache de esa capa para no ejecutarla cada que corramos nuestro contenedor. También sirve para copiar, como lo hacemos en la décima línea.
RUN: le decimos a docker que ejecute un comando. En este caso npm install
EXPOSE: Exponemos el puerto 3000
CMD: Acá le decimos a Docker que ejecute este comando al momento de ejecutar nuestro container. En este caso correrá la aplicación.

dockerignore: es casi igual al gitignore, pero para docker.

No es claro el inicio del curso, mezclan muchas temas a la vez, o este es una continuación del curso de Docker?

# Buscar imagen origen
FROM node:11.1.0-alpine 

#Directorio en el que vamos a trabajar
WORKDIR /app

# 
ADD package.json package-lock.json /app/
RUN npm install

#Configuramos el puerto que se va a exponer
EXPOSE 3000

#
ADD . /app
#Ejecutar la razon por la cual se ejecuta node es para que se encuentre en el PID 1
CMD ["node", "index"]

Se manejan algunos conceptos muy de Docker pero al dar una repasada en lo que menciona podemos continuar con el curso

Para aprender un poco más del fichero package-lock.json para el control de las versiones de las dependencias les recomiendo el siguiente link

Si la verdad en este video me siento aprendiendo de Doker mas no de DevOps.

Para ser el inicio del curso está mal organizado, creo que primero se debió explorar conceptos de DevOps y su cultura antes de entrar en herramientas, así como acá se requiere conocer Docker previamente más adelante puede ser cualquier otra

Yo termine luego de algunas semanas el curso de Docker antes de continuar con el curso de DevOPs

Para acceder a este proyecto: https://github.com/elbuo8/platzi-scripts
(la carpeta de este curso es webapp)

no entiendo como habla este profesor

Manejar dependencias es algo muy importante cuando se trata de desarrollar software, no importa el lenguaje, debemos tener siempre nuestras dependencias “vendor” o “lock in”, es decir, que siempre se instalen una versión que ya hayamos probado.

El Dockerfile siempre empieza con un FROM, a través del cual busca una imagen base sobre la cual crear el nuevo contenedor.
Así como es importante fijar dependencias, es también muy importante manejar versiones exactas de las imágenes, porque pueden tener cambios en nuevas versiones que afecten o impidan el funcionamiento correcto de nuestros contenedores. La idea es tener siempre algo reproducible.

Es recomendable, que no corramos todo en /root; la buena práctica es crear un nuevo directorio donde copiemos nuestro servicio o aplicación. Para esto, utilizamos el comando WORKDIR dentro del Dockerfile.

Los container guardan layers o capas para hacer caché cuando un mismo Dockerfile vuelva a ser construido, y de esta manera, se toma menos tiempo dicha construcción al reutilizar capas similares. Por esto, es una buena práctica definir primero los comandos que no cambian la imagen y de último, aquellos que sí la modifican. De manera que si 2 capas cambian en una imagen de siete, sólo cambien las 2 al ser construidas y no más de ellas al no estar ordenados los comandos de forma correcta.
Al manejar dependencias con versiones exactas, no se debería volver a ejecutar el paso de instalación de las mismas en cada construcción de una imagen si no se modificó el archivo en donde se definen; y si se modificó, las dependencias que ya habían sido instaladas deberían tener exactamente el mismo comportamiento que la imagen anterior.

Es muy importante también utilizar .dockerignore, puesto que pueden ser transferidos archivos exclusivos de la máquina desde donde se construye la imagen, a ella. Uno de los casos más comunes de su utilización, es para evitar que las dependencias de nuestra máquina local sean añadidas a la imagen en construcción (las dependencias compiladas de un sistema operativo ocasionarán problemas en otro kernel).

Nuestro objetivo es reducir al máximo la posibilidad de errores.

De los cursos que he realizado en Platzi el de Docker ha sido el más universal de todos. Casi siempre se nombra o se utilizar para algo.

Entendiendo el Dockerfile

No es claro el inicio del curso, mezclan muchas temas a la vez, o este es una continuación del curso de Docker?

# Buscar imagen origen
FROM node:11.1.0-alpine 

#Directorio en el que vamos a trabajar
WORKDIR /app

# 
ADD package.json package-lock.json /app/
RUN npm install

#Configuramos el puerto que se va a exponer
EXPOSE 3000

#
ADD . /app
#Ejecutar la razon por la cual se ejecuta node es para que se encuentre en el PID 1
CMD ["node", "index"]

Se manejan algunos conceptos muy de Docker pero al dar una repasada en lo que menciona podemos continuar con el curso

Para aprender un poco más del fichero package-lock.json para el control de las versiones de las dependencias les recomiendo el siguiente link

Si la verdad en este video me siento aprendiendo de Doker mas no de DevOps.

Para ser el inicio del curso está mal organizado, creo que primero se debió explorar conceptos de DevOps y su cultura antes de entrar en herramientas, así como acá se requiere conocer Docker previamente más adelante puede ser cualquier otra

Yo termine luego de algunas semanas el curso de Docker antes de continuar con el curso de DevOPs

Para acceder a este proyecto: https://github.com/elbuo8/platzi-scripts
(la carpeta de este curso es webapp)

no entiendo como habla este profesor

Manejar dependencias es algo muy importante cuando se trata de desarrollar software, no importa el lenguaje, debemos tener siempre nuestras dependencias “vendor” o “lock in”, es decir, que siempre se instalen una versión que ya hayamos probado.

El Dockerfile siempre empieza con un FROM, a través del cual busca una imagen base sobre la cual crear el nuevo contenedor.
Así como es importante fijar dependencias, es también muy importante manejar versiones exactas de las imágenes, porque pueden tener cambios en nuevas versiones que afecten o impidan el funcionamiento correcto de nuestros contenedores. La idea es tener siempre algo reproducible.

Es recomendable, que no corramos todo en /root; la buena práctica es crear un nuevo directorio donde copiemos nuestro servicio o aplicación. Para esto, utilizamos el comando WORKDIR dentro del Dockerfile.

Los container guardan layers o capas para hacer caché cuando un mismo Dockerfile vuelva a ser construido, y de esta manera, se toma menos tiempo dicha construcción al reutilizar capas similares. Por esto, es una buena práctica definir primero los comandos que no cambian la imagen y de último, aquellos que sí la modifican. De manera que si 2 capas cambian en una imagen de siete, sólo cambien las 2 al ser construidas y no más de ellas al no estar ordenados los comandos de forma correcta.
Al manejar dependencias con versiones exactas, no se debería volver a ejecutar el paso de instalación de las mismas en cada construcción de una imagen si no se modificó el archivo en donde se definen; y si se modificó, las dependencias que ya habían sido instaladas deberían tener exactamente el mismo comportamiento que la imagen anterior.

Es muy importante también utilizar .dockerignore, puesto que pueden ser transferidos archivos exclusivos de la máquina desde donde se construye la imagen, a ella. Uno de los casos más comunes de su utilización, es para evitar que las dependencias de nuestra máquina local sean añadidas a la imagen en construcción (las dependencias compiladas de un sistema operativo ocasionarán problemas en otro kernel).

Nuestro objetivo es reducir al máximo la posibilidad de errores.

De los cursos que he realizado en Platzi el de Docker ha sido el más universal de todos. Casi siempre se nombra o se utilizar para algo.

Entendiendo el Dockerfile