Brindando Servicios Con Rocket Container

UNIVERSIDAD MAYOR DE SAN SIMON
FACULTAD DE CIENCIAS Y TECNOLOGIA

DIRECCIÓN DE POSGRADO
“BRINDANDO SERVICIOS CON ROCKET

CONTAINER”
TRABAJO FINAL PRESENTADO PARA OBTENER EL

CERTIFICADO DE DIPLOMADO EXPERTO EN DESARROLLO
DE APLICACIONES EMPRESARIALES VERSIÓN II
.
Postulante: MARCO ANTONIO CARRILLO PADILLA

Tutor: ING. ABEL RAÚL DÍAZ CASTILLO
Cochabamba – Bolivia
2019
Agradecimientos
Gracias a Dios por darme a mis padres y gracias a ello la vida.
No ha sido sencillo el camino hasta ahora, pero gracias a sus

aportes, a su amor, a su inmensa bondad y apoyo, lo complicado
de lograr esta meta se ha notado menos, les agradezco y hago
presente mi gran afecto hacia ustedes mi hermosa familia, mis
padres, hermanos, mi esposa y mi hermosa hija.
A mi tutor Ing. Abel Raúl Díaz Castillo, por la colaboración que

me brindo a lo largo del proyecto.
A Digital Harbor por abrir las puertas para poder realizar este
diplomado de doble titulación.
A mis amigos que me ayudaron y apoyaron en los módulos de

nuestro diplomado.
¡Muchas Gracias!
TABLA DE CONTENIDOS
RESUMEN 1
INTRODUCCIÓN 2
1 GENERALIDADES 3
1.1 Antecedentes Generales 3
1.2 Antecedentes Específicos 4
2 METODOLOGÍA 5
3 CONTENEDORES 5
3.1 Definición de Contenedores 6
3.2 Importancia de los Contenedores 6
3.3 Funcionamiento de los Contenedores 7
3.4 Gestión de los contenedores en las Empresas 8
4 ROCKET CONTAINER 9
4.1 Instalación de Rocket 11
4.1.1 Instalación en Arco 12
4.1.2 Instalación en CentOS 12
4.1.3 Instalación en Linux Container 12
4.1.4 Instalación en Debian 13
4.1.5 Instalación en Fedora 13
4.1.6 Instalación en Gentoo 14
4.1.7 Instalación en Nixos 14
4.1.8 Instalación en openSUSE 14
4.1.9 Instalación en Linux Ubuntu 15
4.2 Comandos Rocket 15
4.2.1 Descarga de Imágenes (ACIs) 15
4.2.2 Ejecutar Pods 16
4.2.3 Inspección y Administración de Pods 16
4.2.4 Interactuando con el Store de la imagen local 16
4.2.5 Servicio de metadatos 16
4.2.6 Servicio API 17
4.2.7 Opciones Globales 17
4.3 Primeros pasos con Rocket Container 18
4.3.1 Crea una aplicación hello.go 19
4.3.2 Construye un binario Go enlazado estáticamente 19
4.3.3 Crea la imagen 20
4.3.4 Ejecutar la Imagen de aplicación local 20
4.3.5 Probamos con curl 20
4.4 Ejecutando imágenes Docker con Rocket 21
4.5 Diferencias entre Rocket y Docker 22
4.5.1 Seguridad de la imagen del contenedor 23
4.5.2 Prevenir los ataques de escala de privilegios “raíz” 24
4.5.3 Flexibilidad en publicar o compartir imágenes 25
4.5.4 Tamaño del código base 25
4.5.5 Portabilidad a otros sistemas de contenedores 26
4.5.6 Diferencia de Arquitectura 26
4.5.7 ¿Cuál debería elegir? 27
5 SERVICIOS CON ROCKET CONTAINER 27

5.1 Rocket Compose (rkt-compose) 27
5.1.1 Características 27
5.1.2 Creación del archivo rkt-compose.yml 28
5.1.3 Creación de la red 28
5.1.4 Instalación y Ejecución de rkt-compose.yml 28
5.2 Mysql 30
5.3 Apache 31
5.4 Proyecto en Wordpress 31
6 CONCLUSIONES 33
7 GLOSARIO 34
8 BIBLIOGRAFÍA 37
TABLA DE FIGURAS
Figura 1. Historia de los contenedores (hoplasoftware, 2018) 6
Figura 2. CoreOS (cloudtweaks, 2015) Figura 3. Logo de Rocket (coreos, 2019) 9
Figura 4. Instalando rkt custom en Linux Container (coreos, 2019) 12
Figura 5. rkt empaquetado para gentoo (Medico, 2019) 14
Figura 6. Global Options (coreos, 2019) 17
Figura 7. fetching image redis (oblancarte, 2017) 21
Figura 8. Container image security (Visakh, 2016) 23
Figura 9. Verificación de la firma de la imagen (Visakh, 2016) 23
Figura 10. Preventing “root” privilege scalation attacks (Visakh, 2016) 24
Figura 11. Protocolo HTTPS utilizado por Rocket (Visakh, 2016) 25
Figura 12. Diferencia de Arquitectura (Jonge, 2016) 26
Figura 13. Ejemplo rkt-compose-yaml (trusch, github, 2017) 28
Figura 14. Configuracion de red “my-net” (Elaboración Propia) 28
Figura 15. Ejecutando rkt-compose.yaml (Elaboración propia) 29
Figura 16. Ejecución de pod (Elaboración propia) 30
Figura 17. download image mysql (Elaboración propia) 30
Figura 18. running mysql image (Elaboración propia) 30
Figura 19. download apache image (Elaboración propia) 31
Figura 20. download Wordpress image (Elaboración propia) 31
Figura 21. running wordpress image (Elaboración propia) 32
Figura 22. Probando Wordpress en el navegador (Elaboración propia) 32
Figura 23. Configurando Wordpress (Elaboración propia) 32

Brindando servicios con rocket container – Marco Antonio Carrillo Padilla
RESUMEN
La presente monografía se centra en el estudio de las características de Rocket Container el cual

nos permitirá brindar servicios y microservicios de una manera rápida y sencilla además de poder
resaltar las ventajas que se tiene al usar la tecnología de los contenedores para poder optimizar
tiempos en el proceso de deployment, y de esta manera poder olvidarse de todas las
dependencias que conllevan las aplicaciones para poder ejecutarse ya que esta tecnología nos
provee un ambiente totalmente independiente del Sistema Operativo.
Se realizará una revisión bibliográfica de Rocket Container el mismo que en la actualidad es el

primer competidor de Docker, siendo este último el más usado en la actualidad, tambien veremos
una prevé comparación entre los mencionados, que gracias a ello podremos identificar
diferencias de gran importancia.
Por otro lado mostraremos ejemplos claros y sencillos además de la puesta en marcha del
contenedor Rocket Container con distintos servicios y microservicios que corren paralelamente
en un mismo Sistema Operativo.
También se realizará un breve estudio sobre Rocket-Compose quien nos ayudará a orquestar
servicios y microservicios paralelamente comunicándolos entre sí, que gracias a ello podremos
sustentar nuestro objetivo “Brindando servicios con Rocket Container”.
Como Preámbulo podemos incentivar a nuestros lectores a inclinarse por esta tecnología,
tomando como punto de partida esta monografía, debido a que es un mundo relativamente nuevo
y que tiene todavía mucho que ofrecernos.
1
INTRODUCCIÓN
El desarrollo de software de aplicaciones web ha ido creciendo a pasos agigantados en los

últimos años, cuyo crecimiento conlleva para su ejecución muchas dependencias en cuanto se
refiere a los servidores web, el cual se resume en costes de manutención de servidores.
Para los proveedores de servicios web es muy importante el poder escalar rápidamente debido
a la competencia que existe, dado que su objetivo principal es mantener a sus clientes
satisfechos y poder minimizar los costes de manutención de servidores debido al uso innecesario
de recursos, es ahí donde hacen su ingreso la tecnología de contenedores dando solución a este
problema. (TERRAZAS, 2018)
El objetivo de la monografía es ver la facilidad con la que se brinda servicios y micro-servicios a

través de la tecnología de contenedores usando Rocket Container de Core OS que es una
tecnología de virtualización relativamente nueva que nació en 2014, ya que existen varios
indicadores que pueden definir por qué usar o no esta tecnología, uno de los más importantes
que podríamos resaltar es el tiempo y los recursos necesarios que se necesita para poder
levantar un nuevo servidor web y la facilidad que representa escalar el mismo.
En la presente monografia se verá todas las características de rocket container desde su

instalación en las distintas distribuciones de Linux, los distintos comandos que presenta para
poder levantar las imágenes, las características que presenta en cuanto a seguridad,
escalabilidad y portabilidad, las diferencias que tiene frente a Docker que es el más usado en la
actualidad, etc. hasta poder comunicar los servicios mediante Rocket-Compose, bases
suficientes las cuales nos ayudaran a sustentar nuestro objetivo principal.
Por otro lado también gracias al estudio que se realizará se busca guiar tanto a las empresas,
instituciones y/o personas al momento de tomar una decisión sobre que tecnología utilizar para
poder brindar sus servicios web y de esta manera poder evitarse la pérdida de tiempo en cambios
de migraciones, incompatibilidad de Sistemas Operativos, pérdida de recursos innecesarios de
hardware que conllevan perdidas económicas, etc.
2
1 GENERALIDADES
1.1 Antecedentes Generales
Cabe mencionar que antes de que los contenedores ganaran popularidad, un enfoque previo
eran las máquinas virtuales. Aquí, un servidor físico podía usarse para múltiples aplicaciones a
través de la tecnología de virtualización, también conocida como máquina virtual, donde cada
máquina virtual contiene el sistema operativo completo, así como la aplicación para ejecutar
según (RAMÍREZ, 2016)
El servidor físico que ejecuta varias máquinas virtuales, cada una con su propio sistema
operativo, con una única capa de emulación de hipervisor en la parte superior. Al ejecutar varios
sistemas operativos simultáneamente, hay una gran cantidad de gastos generales en el servidor
a medida que los recursos se utilizan, y el número de máquinas virtuales se limita a unos pocos
según (RAMÍREZ, 2016)
En contraste, con la tecnología de contenedores, el servidor ejecuta un solo sistema operativo,

ya que cada contenedor puede compartir este sistema operativo único con los otros
contenedores en el servidor. Las partes del sistema operativo que se comparten se leen solo
para no interferir con los otros contenedores. Esto significa que, en comparación con las
máquinas virtuales, los contenedores requieren menos recursos del servidor con una sobrecarga
menor, y son significativamente más eficientes, por lo que se pueden empaquetar muchos más
contenedores en un solo servidor. Por ejemplo, si bien cada máquina virtual puede requerir
gigabytes de almacenamiento, cada contenedor que ejecuta un programa similar solo necesita
megabytes según (jgarzas, 2015)
Debido al anterior antecedente los contenedores se están apoderando del mundo. Desde VPS
hasta aplicaciones de alojamiento, cada vez más compañías utilizan tecnologías de contenedor
como Docker, LXC, OpenVZ, Rocket (el cual abarcaremos más adelante), etc.
El primer antecedente mencionado por (hoplasoftware, 2018) del uso de una técnica para intentar
ejecutar un proceso aislado dentro de un sistema operativo se remonta a 1979 y fue cuando el
chroot se introdujo como un concepto en desarrollo para sistemas Unix que permitía aislar dentro
una ruta un proceso y sus hijos de modo que, para ellos, esa ruta pareciese ser el directorio raíz.
En 2008, llega a Linux con LXC (Linux Containers) que da soporte al Kernel para los
namespaces.
3
Los namespaces constituyen el elemento base de los contenedores y es una funcionalidad del
Kernel que proporcionan facilidades para crear una abstracción del sistema de modo que, todo
lo que sucede fuera del espacio del contenedor sea invisible al interior. (hoplasoftware, 2018)
Finalmente sobre la base de LXC llega en 2013 Docker y como consecuencia de las debilidades
del ya mencionado nace Rocket Container de Core OS.
1.2 Antecedentes Específicos
Es totalmente evidente que Docker estaba en camino de convertirse en el estándar existente

para la tecnología de contenedores, lo más importante de la computación en nube en 2014.
Luego apareció CoreOS, que fue uno de los principales patrocinadores de Docker hasta el 1 de
diciembre de 2014, cuando lanzó una bomba o podríamos decir un cohete y anunciar una
tecnología competitiva de virtualización de contenedores llamada Rocket. (Sudhi Seshachala,
2015)
El enfoque principal del equipo de CoreOs es la idea de un contenedor como una estructura
elemental de desarrollo de aplicaciones.
Todos los contenedores contribuyen con un “microservicio” que se puede combinar con otros
microservicios para formar aplicaciones distribuidas.
Docker es quizás la tecnología de virtualización ligera más popular utilizada por los
desarrolladores de aplicaciones.
Sin embargo, Docker ahora tiene un competidor - rkt (también conocido como cohete) que
ofrece algunas características únicas.
El proyecto rkt se inició en diciembre de 2014, cuando se descubrió que Docker tenía varios
problemas de seguridad. Rkt fue diseñado para ser una solución más segura, interoperable y
de contenedor abierto en comparación con Docker. (Sudhi Seshachala, 2015)
Desde entonces, Docker ha cubierto mucho terreno para abordar todos los problemas críticos
de seguridad. Sin embargo, vale la pena observar cómo estas dos plataformas difieren en sus
distintas capacidades, con el propósito de ofrecer la mejor explicación y entender los conceptos
de contenedores explicaremos ampliamente que es Rocket y cual su diferencia ante su principal
competidor Docker. (Sudhi Seshachala, 2015)
4
2 METODOLOGÍA
Para el presente trabajo se utilizarán los siguientes métodos de investigación:
● Método Bibliográfico, debido a que se realizará la lectura y compilación de libros relacionados

al tema de estudio.
● Método Analítico, debido a que se procederá a revisar y analizar ordenadamente documentos
relacionados al tema de estudio.
3 CONTENEDORES
Los contenedores son aplicaciones y servicios autónomos que encapsulan todas las
dependencias para que sean fácilmente implementables y actualizables. El beneficio del uso de
los contenedores es que gracias a su naturaleza aislada, un administrador no tiene que
preocuparse de que cada aplicación o servicio interfiera o se afecte entre sí, además de ser muy
rentables ya que eliminan el costo del hardware de la ecuación. Los contenedores están
configurados para funcionar realizando el trabajo en una arquitectura de múltiples contenedores
o clúster. En un clúster de contenedores, hay un único maestro, con los otros contenedores
relacionados designados como nodos donde las funciones del maestro es programar las cargas
de trabajo para los nodos, y también administrar su ciclo de vida y sus actualizaciones.
Los contenedores han revolucionado el mundo de la implementación de aplicaciones y servicios

web haciéndolos autónomos, escalables, fáciles de actualizar, confiables y seguras dado que
solucionan un gran problema de costes y rendimientos de gran mayoría de empresas que brindan
servicios web.
Su historia se remonta al año 1979 con Unix V7 según (hoplasoftware, 2018) hasta la aparición
de Docker en 2013, posteriormente en 2014 hace su aparición el competidor número uno de
Docker Core OS con Rocket el cual abordaremos en la presente monografía.
5
Aquí una ilustración de las diferentes tecnologías de contenedores a lo largo del tiempo.
Figura 1. Historia de los contenedores (hoplasoftware, 2018)
3.1 Definición de Contenedores
dependencias para que sean fácilmente implementables y actualizables, en términos más
simples, los contenedores son aplicaciones independientes, empaquetadas con sus
dependencias, que TI puede implementar y actualizar fácilmente. (tecnologias-informacion,
2018)
Al igual que las máquinas virtuales, los contenedores eliminan la dependencia del hardware de
la ecuación. Los contenedores se distribuyen fácilmente a través de una plataforma virtual, y son
una forma en que su empresa o entidad puede ahorrar dinero, teniendo en cuenta que ahora
tiene la capacidad de implementar múltiples aplicaciones y micro-servicios que no tienen sus
propios requisitos de hardware. (tecnologias-informacion, 2018)
La tecnología de contenedores, también conocida como solo un contenedor, es un método para

empaquetar una aplicación para que pueda ejecutarse, con sus dependencias, aislada de otros
procesos. (tecnologias-informacion, 2018)
Los principales proveedores de computación en la nube pública, incluidos Amazon Web Services,
Microsoft Azure y Google Cloud Platform han adoptado la tecnología de contenedores, con
software de contenedor que tiene nombres que incluyen las opciones populares de Docker,
Apache, ROCKET (pronunciado "cohete") y Kubernetes. (tecnologias-informacion, 2018)
3.2 Importancia de los Contenedores
Los contenedores hacen que sea mucho más fácil para los administradores implementar
aplicaciones y servicios y mantenerlos de manera efectiva.
6
Los contenedores también son un excelente medio para implementar y escalar sitios web.
Imagine que su sitio web básico (servido en una máquina virtual) le permite agregar fácilmente
aplicaciones y/o servicios basados en la web para expandir sus ofertas. (tecnologias-informacion,
2018)
Estas aplicaciones o servicios podrían agregarse sin requerir que sus dependencias sean
satisfechas por la computadora anfitriona.
Con esto listo, ya no tendrá que preocuparse de que la instalación de una nueva aplicación
interfiera con la computadora host o la máquina virtual anfitriona, ya que el contenedor es una
aplicación autónoma. (tecnologias-informacion, 2018)
La importancia de los contenedores comienza en el nivel del servidor. Imagínese que todo lo que
ejecuta en su servidor se realiza de manera tan eficiente que cada aplicación y servicio en
ejecución no compite por recursos de host preciosos o directamente afecta la ejecución de la
máquina host. (tecnologias-informacion, 2018)
Ahí es donde comienza el beneficio de los contenedores. Debido a la naturaleza aislada de los
contenedores, un administrador no tiene que preocuparse de que cada aplicación o servicio
interfiera o se afecte entre sí, además de ser muy rentables ya que eliminan el costo del hardware
de la ecuación. (tecnologias-informacion, 2018)
3.3 Funcionamiento de los Contenedores
Los contenedores están configurados para realizar el trabajo en una arquitectura de múltiples
contenedores, lo que se denomina un clúster de contenedores. En un clúster de contenedores
Kubernetes, hay un único maestro de clúster, con los otros contenedores relacionados
designados como nodos, que son las máquinas de varios trabajadores. Las funciones del
maestro de clústeres es programar las cargas de trabajo para los nodos, y también administrar
su ciclo de vida y sus actualizaciones. (tecnologias-informacion, 2018)
La tecnología de contenedores no es un fenómeno nuevo, y ha sido durante mucho tiempo una

característica central para Linux. El avance en los últimos años de la tecnología de contenedores
se ha vuelto más fácil de usar, y los desarrolladores de software los han aceptado por su
simplicidad y evitar problemas de compatibilidad. También permiten que un programa se
descomponga en partes más pequeñas, que se conocen como microservicios. (tecnologias-
informacion, 2018)
7
La ventaja de tener el programa como microservicios de componentes es que diferentes equipos

pueden trabajar en cada uno de los contenedores por separado siempre y cuando se mantengan
las interacciones entre los diferentes contenedores, lo que facilita el desarrollo del software más
rápido. Finalmente, la tecnología de contenedores permite un control granular completo sobre
los contenedores. (tecnologias-informacion, 2018)
3.4 Gestión de los contenedores en las Empresas
Con tanto software que se ejecuta como contenedores, la administración de los contenedores
ahora se ha convertido en un requisito, y es imposible realizar esta tarea de forma manual.
Se requiere software especializado para la gestión de contenedores, y una solución popular de
código abierto es Kubernetes, que tiene varias distribuciones, incluida Red Hat OpenShift.
El software de administración de contenedores facilita el despliegue de contenedores y funciona
bien con las estrategias de despliegue rápido de la filosofía de DevOps. (campusMVP, 2018)
Otra gran característica de la tecnología de contenedores es su flexibilidad. Con una máquina
virtual, se requieren varios minutos para iniciarse, al igual que la PC de su escritorio se inicia al
comienzo del día. Más bien, con la tecnología de contenedor, como el sistema operativo ya se
está ejecutando en el servidor, un contenedor puede iniciarse en unos pocos segundos. Esto
permite que los contenedores se inicien y detengan según sea necesario, que se flexionen hacia
arriba en un momento de máxima demanda y que se flexionen hacia abajo cuando no se
necesitan. (campusMVP, 2018)
Además, si un contenedor se bloquea, se puede reiniciar rápidamente para que pueda volver a
la tarea. Este tipo de administración se conoce como orquestación de contenedores, y un
software como Docker Swarm puede controlar este tipo de orquestación y distribuir las tareas
entre el clúster de contenedores. (campusMVP, 2018)
Dado que varios contenedores comparten el mismo sistema operativo, existe la preocupación de
que la tecnología de contenedores es menos segura que una máquina virtual. Esto se debe a
que si hay una falla de seguridad en el núcleo del host, esto afectará a múltiples contenedores. Se
han hecho esfuerzos para hacer los contenedores más seguros. Un enfoque incluye a Docker
que requiere una infraestructura de firma para evitar que los contenedores no autorizados se
inicien. También hay un software de seguridad de contenedor, como Twistlock que perfila el
comportamiento de un contenedor y luego cierra un contenedor que cae fuera del perfil esperado.
(campusMVP, 2018)
8
4 ROCKET CONTAINER
Rkt es una alternativa de contenedor ligera y segura a Docker que se construye en base a un
estándar de contenedor abierto conocido como “Contenedor de aplicaciones” o especificación
“appc” el cual permite que las imágenes de rkt se puedan transportar a través de muchos
sistemas de contenedores como Kurma, JetPack. Rocket no involucra a un demonio exterior,
siempre que llame a rkt para ejecutar un contenedor, lo hará sin demora dentro del rango de su
propio árbol de procesos y cgroup, su unidad de ejecución principal de rkt es el pod, una
colección de una o más aplicaciones que se ejecutan en un contexto compartido. RKT permite
a los usuarios aplicar diferentes configuraciones tanto a nivel de pod como a nivel más granular
por aplicación, su arquitectura significa que cada pod se ejecuta directamente en el modelo de
proceso clásico de Unix.
Rkt es un sistema de contenedor desarrollado por CoreOS como una alternativa ligera y segura
a Docker. Se construye en base a un estándar de contenedor abierto conocido como
“Contenedor de aplicaciones” o especificación “appc”. Esto permite que las imágenes de rkt
se puedan transportar a través de muchos sistemas de contenedores (como Kurma, JetPack,
etc.) que siguen el formato abierto “appc”. (Sudhi Seshachala, 2015)
Figura 2. CoreOS (cloudtweaks, 2015) Figura 3. Logo de Rocket (coreos, 2019)
Rocket es otra posibilidad o elección para la ejecución Docker, también está diseñado para
entornos de servidores con los requisitos de seguridad, enlazamiento, velocidad y de producción
más resueltos. El software se compone de dos elementos, cada uno de los cuales es una
herramienta de línea de comandos sencilla y autónoma. (Sudhi Seshachala, 2015)
1) Actool.- Es el primer componente que administra la construcción de
contenedores. Incluso maneja la validación y el descubrimiento de contenedores. (Sudhi
Seshachala, 2015)
9
2) Rkt.- Se llama así, ya que todos los comandos principales de UNIX utilizados en Rocket
son tres letras. Ayuda en el cuidado de la captura y ejecución de imágenes de contenedor.
Contrariamente al enfoque de Dockers, Rocket no involucra a un demonio exterior y estas

herramientas no son solo una interfaz de usuario para conversar con ningún otro
servidor. Siempre que llame a rkt para ejecutar un contenedor, lo hará sin demora dentro del
rango de su propio árbol de procesos y cgroup. (Sudhi Seshachala, 2015)
Se afirmó que el modelo de proceso Docker es fundamentalmente defectuoso, ya que permite
que todo se ejecute a través de un demonio central. Ahora Rocket hace un intento de lograr y
construir cosas de manera diferente a Docker en muchos aspectos. Los siguientes son los puntos
clave que se han tenido en cuenta para crear un contenedor de tiempo de ejecución impecable.
(Sudhi Seshachala, 2015)
1) Composición: Todas las herramientas que se utilizan para descargar, instalar y ejecutar
contenedores deben ser independientes y compactas. (Sudhi Seshachala, 2015)
2) Seguridad: Para proporcionar un mejor aislamiento de seguridad debe ser conectable,
con auditoría de imagen, identidad de aplicación y primitivas de cifrado para una
confianza sólida.
3) Distribución de imágenes: El descubrimiento de imágenes de contenedor debe ser
simple, facilitar un espacio de nombres y distribuirse con protocolos alternativos
intercambiables como BitTorrent e implementaciones en entornos privados sin el requisito
de un registro.
4) Abierto: El formato y el tiempo de ejecución deben estar bien especificados y
desarrollados por una comunidad, permitiendo que las implementaciones independientes
de las herramientas sean consistentes. (Sudhi Seshachala, 2015)
CoreOS Rocket (rkt) es el primer rival creíble al dominio de Docker en el espacio del
contenedor. En pocas palabras, rkt es una tecnología de contenedor más segura, diseñada para
aliviar muchas de las fallas inherentes en el modelo de contenedor de Docker.
“Desde una perspectiva de seguridad y composabilidad, el modelo de proceso Docker, donde

todo funciona a través de un demonio central, es fundamentalmente defectuoso. “Reparar”
Docker significaría esencialmente una reescritura del proyecto, mientras que heredaría todo el
equipaje de la implementación existente”. (Sudhi Seshachala, 2015)
10
RKT es un motor de contenedor de aplicaciones desarrollado para entornos de producción

modernos nativos de la nube. Cuenta con un enfoque de pod nativo, un entorno de ejecución
conectable y un área de superficie bien definida que lo hace ideal para la integración con otros
sistemas. (Sudhi Seshachala, 2015)
La unidad de ejecución principal de rkt es el pod, una colección de una o más aplicaciones que
se ejecutan en un contexto compartido (los pods de rkt son sinónimo del concepto en el sistema
de orquestación Kubernetes). (Sudhi Seshachala, 2015)
RKT permite a los usuarios aplicar diferentes configuraciones (como parámetros de

aislamiento) tanto a nivel de pod como a nivel más granular por aplicación. La arquitectura de
rkt significa que cada pod se ejecuta directamente en el modelo de proceso clásico de Unix (es
decir, no hay un demonio central), en un entorno aislado e independiente. (Sudhi Seshachala,
2015)
RKT implementa un formato de contenedor moderno, abierto y estándar, la especificación de

App Container (appc), pero también puede ejecutar otras imágenes de contenedor, como las
creadas con Docker. (Sudhi Seshachala, 2015)
Desde su introducción por CoreOS en diciembre de 2014, el proyecto rkt ha madurado

enormemente y se usa ampliamente. Está disponible para la mayoría de las principales
distribuciones de Linux y cada lanzamiento de rkt crea paquetes rpm/deb auto contenidos que
los usuarios pueden instalar. Estos paquetes también están disponibles como parte del
repositorio de Kubernetes para permitir las pruebas de la integración de rkt +
Kubernetes. (Sudhi Seshachala, 2015)
4.1 Instalación de Rocket
RKT está disponible para varias las siguientes distribuciones de Linux que mencionaremos a
continuación: (coreos, coreos, 2019)
• Arco
• CentOS
• Contenedor Linux por CoreOS
• Debian
• Fedora
• Gentoo
11
• Nixos
• openSUSE
• Ubuntu (Abarcaremos esta Instalación en la presente monografía)
4.1.1 Instalación en Arco
rkt está disponible en el repositorio de la comunidad y se puede instalar utilizando pacman:

(coreos, coreos, 2019)
4.1.2 Instalación en CentOS
rkt está disponible en CentOS Community Build Service para CentOS 7. Sin embargo,
esto todavía no está listo para el uso de producción debido a problemas pendientes de
actualización del sistema. (coreos, coreos, 2019)
4.1.3 Instalación en Linux Container
Rkt es una parte integral de Linux Continer, instalado con el sistema operativo.
Si se requiere una versión de rkt diferente a la que se suministra con CoreOS Linux Container,
se puede usar una unidad de sistema de control remoto para descargar e instalar una versión
alternativa en el arranque.
La siguiente unidad utilizará curl para descargar rkt, su firma y la clave de firma de la aplicación
CoreOS. El rkt descargado se verifica con su firma y se extrae a / opt / rkt. (coreos, coreos,
2019)
Figura 4. Instalando rkt custom en Linux Container (coreos, 2019)
12
4.1.4 Instalación en Debian
rkt está actualmente empaquetado en Debian sid (inestable). (coreos, coreos, 2019)
Si no ejecuta sid, o desea una versión más nueva, puede instalarla manualmente.
4.1.5 Instalación en Fedora
Desde la versión 24 de Fedora, los paquetes rkt están disponibles en el repositorio

principal. Recomendamos utilizar versiones recientes de Fedora o un paquete instalado
manualmente para tener un binario rkt actualizado. (coreos, coreos, 2019)
La entrada de rkt en la base de datos de paquetes de Fedora rastrea el trabajo de empaquetado

para esta distribución.
Advertencia: SELinux: rkt no funciona con las políticas de SELinux que se envían actualmente
con las versiones 24 y 25 de Fedora. (coreos, coreos, 2019)
Como solución temporal, SELinux se puede desactivar temporalmente:
O permanentemente deshabilitado por la edición /etc/selinux/config:
Advertencia: firewalld: Fedora usa firewalld para definir dinámicamente las zonas de firewall. rkt aún
no está completamente integrado con firewalld. Las reglas predeterminadas de firewalld pueden
interferir con la conectividad de red de los pods rkt. Para solucionar esto, agregue una regla firewalld
para permitir el tráfico de pod: (coreos, coreos, 2019)
172.16.28.0/24 es la subred de la red de pod predeterminada. El comando debe adaptarse

cuando rkt está configurado para usar una red diferente con una subred diferente.
13
Red pod Predeterminada: Consiste en un dispositivo de bucle invertido y un dispositivo

Veth. El par veth crea un enlace punto a punto entre el pod y el host. rkt asignará una dirección
IPv4 de 172.16.28.0/24 para la interfaz veth del pod. Además, establecerá la ruta
predeterminada en el espacio de nombres del pod. Finalmente, habilitará el enmascaramiento
de IP en el host para NAT el tráfico de egreso. (coreos, coreos, 2019)
4.1.6 Instalación en Gentoo
rkt está empaquetado para gentoo y disponible a través de portage. (coreos, coreos, 2019)
Figura 5. rkt empaquetado para gentoo (Medico, 2019)
4.1.7 Instalación en Nixos
rkt se puede instalar en NixOS usando el siguiente comando: (coreos, coreos, 2019)
La fuente de la expresión rkt.nix se puede encontrar en GitHub
4.1.8 Instalación en openSUSE
rkt está disponible en el proyecto de virtualización: contenedores en openSUSE Build

Service. Antes de instalar, es necesario agregar el repositorio adecuado (generalmente
Tumbleweed o Leap): (coreos, coreos, 2019)
14
Instale rkt utilizando zypper:
4.1.9 Instalación en Linux Ubuntu
rkt no está empaquetado actualmente en Ubuntu. En su lugar, instale manualmente usando

el paquete rkt debian que se describirá a continuación. (coreos, coreos, 2019)
Paquetes mantenidos por rkt: Como parte del proceso de compilación rkt, se construyen los
paquetes rpm y deb. Si necesita usar la última versión de rkt, o su distribución no incluye rkt,
están disponibles. (coreos, coreos, 2019)
Actualmente, el proyecto rkt upstream no mantiene su propio repositorio, por lo que los usuarios
de estos paquetes deben actualizarse manualmente basado en rpm.
4.2 Comandos Rocket
4.2.1 Descarga de Imágenes (ACIs)
rkt ejecuta aplicaciones empaquetadas de acuerdo con la especificación de la imagen del

contenedor de aplicaciones de código abierto. Los ACI consisten en el sistema de archivos raíz
del contenedor de la aplicación, un manifiesto y una firma opcional.
ACI se nombran con una estructura similar a la URL. Este esquema de denominación permite
un descubrimiento descentralizado de ACI, firmas relacionadas y claves públicas. rkt utiliza
estos consejos para ejecutar meta descubrimiento. (coreos, coreos, 2019)
• trust
• fetch
15
4.2.2 Ejecutar Pods
rkt puede ejecutar ACIs identificadas por nombre, hash, ruta de archivo local o URL. Si un ACI
no se ha almacenado en caché en el disco, rkt intentará encontrarlo y descargarlo. Para usar
el servicio de metadatos de rkt , habilite el registro con la --mds-registerbandera al invocarlo .
(coreos, coreos, 2019)
• run
• stop
• enter
• prepare
• run-prepared
4.2.3 Inspección y Administración de Pods
rkt proporciona subcomandos para enumerar, obtener el estado y limpiar sus pods. (coreos,
coreos, 2019)
• list
• status
• export
• gc
• rm
• cat-manifest
4.2.4 Interactuando con el Store de la imagen local
rkt proporciona subcomandos para enumerar, inspeccionar y exportar imágenes en su tienda

local. (coreos, coreos, 2019)
• Image
4.2.5 Servicio de metadatos
El servicio de metadatos está diseñado para ayudar a ejecutar las aplicaciones en su entorno
de ejecución y afirmar su identidad de pod. En particular, el servicio de metadatos expone el
contenido del pod y los manifiestos de imagen, así como un método conveniente para buscar
16
anotaciones. Finalmente, el servicio de metadatos proporciona un pod con identidad verificable

criptográficamente. (coreos, coreos, 2019)
4.2.6 Servicio API
El servicio API permite a los clientes listar e inspeccionar pods e imágenes que se ejecutan
bajo rkt. (coreos, coreos, 2019)
• api-service
4.2.7 Opciones Globales
Además de los indicadores utilizados por los rkt comandos individuales, rkt tiene un conjunto
de opciones globales que son aplicables a todos los comandos. (coreos, coreos, 2019)
Figura 6. Global Options (coreos, 2019)
• none: todas las funciones de seguridad están habilitadas.

• http: Permitir conexiones HTTP. Tenga en cuenta que esto enviará las credenciales
como texto claro, permitiendo que cualquier persona con acceso a su red pueda
obtenerlas. Tampoco llevará a cabo ninguna validación del servidor remoto, lo que hace
posible que un atacante se haga pasar por el servidor remoto. Esto se aplica
específicamente a la obtención de imágenes, firmas y gpg pubkeys. (coreos, coreos,
2019)
17
• Image: desactiva la verificación de las firmas de la imagen. Si alguien puede reemplazar

la imagen en el servidor con una modificada o está en posición de hacerse pasar por el
servidor, podrá obligarlo a ejecutar código arbitrario. (coreos, coreos, 2019)
• tls: Acepte cualquier certificado del servidor y cualquier nombre de host en ese
certificado. Esto permitirá a los atacantes falsificar el servidor remoto y proporcionar
imágenes maliciosas. (coreos, coreos, 2019)
• pubkey: Permite obtener claves de publicación mediante conexiones inseguras
(mediante conexiones HTTP o desde servidores con certificados no verificados). Esto
amplía ligeramente el significado del flag --trust-keys-from-https.
Esto hará posible que un atacante pueda falsificar el servidor remoto, lo que podría
proporcionar claves falsas y permitirles proporcionar imágenes de contenedor que han
sido manipuladas. (coreos, coreos, 2019)
• capabilities: Da todas las capacidades a las aplicaciones. Esto permite a un atacante
que puede ejecutar código en el contenedor para escalar trivialmente a privilegios de
root en el host. (coreos, coreos, 2019)
• paths: deshabilita las rutas inaccesibles y de solo lectura. Esto hace que sea más fácil
para un atacante que puede controlar un solo contenedor ejecutar código en el sistema
host, lo que potencialmente les permite escapar del contenedor. Esto también filtra
información adicional. (coreos, coreos, 2019)
• seccomp: desactiva seccomp. Esto aumenta la superficie de ataque disponible para un
atacante que puede obtener control sobre un solo contenedor, lo que potencialmente
hace que sea más fácil para ellos escapar del contenedor.
• all-fetch: desactiva las siguientes comprobaciones de seguridad: image, tls, http.
• all-run: deshabilita las siguientes comprobaciones de seguridad: capabilities, route,
seccomp.
• all: desactiva todos los controles de seguridad
4.3 Primeros pasos con Rocket Container
En esta sección crearemos un ejemplo desde cero usando rocket y acbuild, posteriormente lo
desplegaremos usando el comando rkt run. Crear un servicio o microservicio y poderlo ejecutar
en cuestión de segundos es muy facil usando la tecnologia de contenedores como lo es rocket
container.
18
La siguiente guía le mostrará cómo construir y ejecutar una aplicación Go auto-contenida

usando rkt, la implementación de referencia de la especificación del contenedor de
aplicaciones. Si no estás en Linux, debes hacer todo esto dentro del rkt Vagrant. (coreos,
coreos, 2019)
4.3.1 Crea una aplicación hello.go
package main
import (
"log"
"net/http"
)
func main() {
http.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) {
log.Printf("request from %v\n", r.RemoteAddr)
w.Write([]byte("Hello Digital Harbor\n"))
})
log.Fatal(http.ListenAndServe(":5000", nil))
}
4.3.2 Construye un binario Go enlazado estáticamente
A continuación necesitamos construir nuestra aplicación. Vamos a vincular estáticamente

nuestra aplicación para que podamos enviar una imagen de contenedor de aplicaciones sin
dependencias externas. (coreos, coreos, 2019)
Antes de continuar, verifique que el binario producido esté enlazado estáticamente:
19
4.3.3 Crea la imagen
Para crear la imagen, podemos usar acbuild, que se puede descargar a través de uno de
los releases in te conteiner/budil repositorio.
Los siguientes comandos crearán un ACI que contiene nuestra aplicación y metadatos
importantes. (coreos, coreos, 2019)
4.3.4 Ejecutar la Imagen de aplicación local
Tenga en cuenta que --insecure-options=image es necesario porque, de forma predeterminada,

rkt espera que nuestras imágenes estén firmadas. Consulte la Guía de firma y verificación para
obtener más detalles.
En este punto, nuestra aplicación “hello” se está ejecutando y está lista para manejar solicitudes
HTTP. (coreos, coreos, 2019)
4.3.5 Probamos con curl
De forma predeterminada, rkt asignará una dirección IP al contenedor en ejecución. Utilice rkt
list para listar todos los contenedores: (coreos, coreos, 2019)
Entonces podemos hacer la petición con curl al IP: 172.16.28.2 puerto 5000:
20
4.4 Ejecutando imágenes Docker con Rocket
RKT cuenta con soporte nativo para recuperar y ejecutar imágenes de contenedor Docker.
Para hacer referencia a una imagen de Docker, usar el prefijo para obtener o
ejecutar imágenes.
Tenga en cuenta que las imágenes de Docker no admiten la verificación de firmas y, por lo
tanto, es necesario usar: (coreos, coreos, 2019)
Como ejemplo simple, ejecutemos la última imagen del contenedor redis desde el registro de
Docker predeterminado:
Figura 7. fetching image redis (oblancarte, 2017)
Esto se comporta de manera similar al cliente Docker: si no se nombra un registro específico, se

usa Docker Hub de forma predeterminada.
Al igual que con Docker, se pueden usar registros alternativos especificando el registro como
parte de la referencia de la imagen. Por ejemplo, el siguiente comando buscará
una imagen nginx Docker alojada en quay.io : (coreos, coreos, 2019)
21
El hash impreso en la línea final representa la ID de imagen del ACI convertido.
Una vez que se ha recuperado la imagen, se puede ejecutar haciendo referencia a este hash:
4.5 Diferencias entre Rocket y Docker
Rkt la verificación de la firma la realiza de forma predeterminada entonces tan pronto como se
descarga una imagen del servidor, se verifica de forma cruzada con la firma del editor para ver
si se ha manipulado de alguna manera, ademas ejecuta contenedores como usuarios sin
privilegios, de modo que incluso si un usuario se rompe, no pueden afectar a otros
contenedores o tomar el control del servidor. rkt usa el protocolo HTTPS para descargar
imágenes y usa una meta descripción en el servidor web para señalar la ubicación, entonces,
ese es un servidor menos para mantener, y más fácil de acceder para su equipo de trabajo.
rkt, en contraste usa una arquitectura modular donde las características son desarrolladas
como binarios independientes por diferentes proveedores, el código base se mantiene lo más
pequeño posible para reducir el área de la superficie de ataque con el cual asegura que incluso
si un subcomponente como etcd está comprometido, el daño se limitaría a lo que el programa
puede acceder. rkt utiliza un formato de contenedor de código abierto conocido como "appc",
cualquier imagen del servidor creada con rkt se puede portar fácilmente a otro sistema de
contenedores siempre que siga el formato abierto "appc".
El proyecto rkt se inició en diciembre de 2014, cuando se descubrió que Docker tenía varios
problemas de seguridad. Rkt fue diseñado para ser una solución más segura, interoperable y
de contenedor abierto en comparación con Docker.
Desde entonces, Docker ha cubierto mucho terreno para abordar todos los problemas críticos
de seguridad. Sin embargo, vale la pena observar cómo estas dos plataformas difieren en sus
distintas capacidades. (UpGuard, 2018)
Aquí hay una lista de las principales diferencias:
22
4.5.1 Seguridad de la imagen del contenedor
Una gran cosa acerca de Docker es que hay un registro público desde el cual cualquiera puede
descargar imágenes optimizadas del servidor de aplicaciones. Entonces, si quieres un servidor
Nginx optimizado para la aplicación web Magento, obtendrás uno del registro de Docker.
Sin embargo, hay un peligro oculto en esto. Es posible que un atacante reemplace una imagen
del servidor con otra infectada con malware. (Visakh, 2016)
Figura 8. Container image security (Visakh, 2016)
Antes de la versión 1.8, Docker no tenía una manera de verificar la autenticidad de una imagen
de servidor. Pero en v1.8, se introdujo una nueva característica llamada Docker Content
Trust para firmar y verificar automáticamente la firma de un editor. (Visakh, 2016)
En rkt, la verificación de la firma se realiza de forma predeterminada. Entonces, tan pronto

como se descarga una imagen del servidor, se verifica de forma cruzada con la firma del editor
para ver si se ha manipulado de alguna manera. (Visakh, 2016)
Figura 9. Verificación de la firma de la imagen (Visakh, 2016)
23
Entonces, mientras esté ejecutando la última versión de Docker (v1.12) o Rkt (v1.3), estará a
salvo de este problema. (Visakh, 2016)
4.5.2 Prevenir los ataques de escala de privilegios “raíz”
Docker se ejecuta con privilegios de super-usuario (también conocido como "raíz") y separa
nuevos contenedores como su subproceso. El problema con eso es que una vulnerabilidad en
un contenedor o una contención deficiente pueden dar a un atacante nivel de acceso de acceso
a todo el servidor. CVE-2014-9357 fue una de esas vulnerabilidades. (Visakh, 2016)
Claro, Docker siempre recomendó ejecutar contenedores dentro de SELinux o AppArmor, pero
muchos propietarios de servidores lo consideran demasiado complicado y omiten el paso.
(Visakh, 2016)
Rkt ideó una mejor solución donde los nuevos contenedores nunca se crean a partir de un
proceso con privilegios de raíz. De esta forma, incluso si ocurre una ruptura de contenedor, el
atacante no puede obtener privilegios de root. (Visakh, 2016)
Figura 10. Preventing “root” privilege scalation attacks (Visakh, 2016)
Como una forma de contener esta amenaza, Docker carga los módulos de seguridad de
AppArmor de forma predeterminada. Esto evita que un usuario (contenedor) vea los archivos
o el contenido de la memoria de otro usuario. (Visakh, 2016)
Además, muchas características adicionales como espacios de nombre de usuario, ejecución
sin privilegios, etc. se pueden configurar para mantener seguros los contenedores de Docker.
En algunos sistemas, como Docker, si un usuario puede salir de un contenedor utilizando un
exploit del Kernel, el atacante puede controlar todo el servidor físico y cualquier almacén de
24
datos adjunto. Por supuesto, Docker puede protegerse para evitar que un usuario se escape,
pero eso es seguridad “adicional”, como lo mencionamos anteriormente. (Visakh, 2016)
En contraste, rkt ejecuta contenedores como usuarios sin privilegios, de modo que incluso si
un usuario se rompe, no pueden afectar a otros contenedores o tomar el control del servidor.
(Visakh, 2016)
4.5.3 Flexibilidad en publicar o compartir imágenes
Al desarrollar aplicaciones, podría ser necesario compartir imágenes de contenedor con sus
socios tecnológicos. Si desea compartir los contenedores de Docker, deberá configurar un
registro privado especial en sus servidores o alojarlo en una cuenta de pago de Docker para
compartirlo con su equipo de trabajo. (Visakh, 2016)
Para rkt, solo necesitas tu servidor web para ello. rkt usa el protocolo HTTPS para descargar
imágenes y usa una meta descripción en el servidor web para señalar la ubicación. Entonces,
ese es un servidor menos para mantener, y más fácil de acceder para su equipo de trabajo.
(Visakh, 2016)
Figura 11. Protocolo HTTPS utilizado por Rocket (Visakh, 2016)
HTTPS es solo una forma de distribuir archivos ACI. Usando el comando rkt torrent pull, las
imágenes se pueden descargar en torrents. (Visakh, 2016)
4.5.4 Tamaño del código base
Docker agrega todas sus características a un solo archivo de programa monolítico, lo que
significa que la cantidad de líneas de código sigue aumentando a medida que sale cada nueva
versión. Y aquí radica un problema de seguridad. Una sola vulnerabilidad en cualquiera de las
miles de líneas de código puede comprometer todo el programa y, en esencia, otorgar acceso
de raíz a un atacante. (Visakh, 2016)
25
rkt, en contraste usa una arquitectura modular donde las características son desarrolladas
como binarios independientes por diferentes proveedores. El código base se mantiene lo más
pequeño posible para reducir el área de la superficie de ataque. Esto asegura que incluso si
un subcomponente como etcd está comprometido, el daño se limitaría a lo que el programa
puede acceder. (Visakh, 2016)
4.5.5 Portabilidad a otros sistemas de contenedores
Nuevos sistemas de contenedores salen todo el tiempo. ¿Y si mañana hay una mejor
tecnología de contenedores? Con Docker, la migración a una nueva tecnología de contenedor
podría ser un problema, ya que utiliza un formato de imagen propietario.
En contraste, rkt utiliza un formato de contenedor de código abierto conocido como "appc". Por
lo tanto, cualquier imagen del servidor creada con rkt se puede portar fácilmente a otro sistema
de contenedores siempre que siga el formato abierto "appc". (Visakh, 2016)
Al adherirse a un estándar abierto, rkt no impone un bloqueo de proveedor. Esto ayuda a los
propietarios de sistemas a migrar sin problemas a otro sistema de contenedores que se adapte
mejor a sus requisitos. (Visakh, 2016)
4.5.6 Diferencia de Arquitectura
A diferencia de Docker, si usa systemd para iniciar los contenedores rkt, en realidad está
monitoreando el proceso del contenedor en lugar de monitorear un proceso cliente que se
conecta a un demonio que a su vez (directa o indirectamente, dependiendo de su versión de
Docker) inicia el contenedor. La siguiente imagen lo ilustra. (Jonge, medium, 2016)
Figura 12. Diferencia de Arquitectura (Jonge, 2016)
26
4.5.7 ¿Cuál debería elegir?
Si ya ha invertido bien en un sistema Docker y lo ha bloqueado firmemente, no tiene una razón

para cambiar de inmediato. Pero si usted está planeando en alejarse de los servidores
dedicados tradicionales a un sistema virtualizado rkt podría valer la pena echarle un vistazo.
De cualquier manera, es importante saber que la confiabilidad del sitio depende de qué tan
bien pueda predecir los puntos de falla del sistema de producción y diseñar las redundancias
del sistema para contrarrestarlo. (Visakh, bobcares, 2016)
El conocimiento de las ventajas y desventajas de las tecnologías de la competencia puede ser

útil al diseñar un sistema de este tipo.
5 SERVICIOS CON ROCKET CONTAINER

En este apartado ejecutaremos varias imágenes con rkt container con facilidad y rapidez
brindaremos servicios y micro-servicios con cada imagen levantada, también los
orquestaremos y/o comunicaremos usando rkt-compose al igual como lo hace Docker con
Docker-compose.
5.1 Rocket Compose (rkt-compose)
Una herramienta para preparar y ejecutar rkt pods rápidamente. (trusch, 2017)
5.1.1 Características
• Escribir plantillas pod simplificadas en yaml.

• Obtención automática de imágenes.
• URLs de ACI y Docker compatibles.
• Podemos especificar redes.
• Crea appc conformes pod-manifiest.
• Podemos usar comandos como start/stop/restart/status.
• Lleva un registro de visualización de su pod.
27
5.1.2 Creación del archivo rkt-compose.yml
Figura 13. Ejemplo rkt-compose-yaml (trusch, github, 2017)
5.1.3 Creación de la red
Creamos la red “my-net” en “/etc/rkt/net.d/” en un archivo de configuración “.conf”.
Figura 14. Configuracion de red “my-net” (Elaboración Propia)
5.1.4 Instalación y Ejecución de rkt-compose.yml
• Install rkt-compose: go get github.com/trusch/rkt-compose.

• Make it available for all users: sudo ln -s $GOPATH/bin/rkt-compose
/usr/local/bin/rkt-compose.
• Create a folder and paste the example template into a file named rkt-
compose.yaml.
28
• Run sudo rkt-compose run –i.
• Inicia tu pod con starting up.

• Press Ctrl-C to stop the pod (you are in interactive mode via the -i flag).
• Run sudo rkt-compose start para ejectutar en segundo plano.
• Verifica tu pod: sudo rkt-compose status.
• Check the logs of etcd: sudo rkt-compose logs -- -u etcd.
• Detiene el pod: sudo rkt-compose stop.
Figura 15. Ejecutando rkt-compose.yaml (Elaboración propia)
Como vimos en el ejemplo anterior pudimos levantar dos imágenes diferentes en un pod con id
“c0235601”, una con la imagen “quay.io/coreos/etcd” cuya imagen brinda el servicio de ser
un almacén de valor-clave confiable y distribuido para los datos más críticos de un sistema
distribuido, centrado en ser:
Simple: API bien definida, orientada al usuario (gRPC)
Seguro: TLS automático con autenticación cert opcional del cliente
Rápido: puntos de referencia de 10,000 escrituras / seg.
Confiable: distribuido correctamente utilizando Raft
Por otro lado también levantamos la imagen “debian” el cual podría ayudarnos para un testing,
ambas imágenes están conectadas a la red “my-net” que gracias a ello y rkt-compose están
comunicados entre sí, podemos observar con que facilitad pudimos comunicar dos servicios
alojados en diferentes host fácilmente.
29
Figura 16. Ejecución de pod (Elaboración propia)
5.2 Mysql
En este apartado nos descargaremos la imagen de mysql y la iniciaremos:
“rkt --insecure-options=image run Docker://mysql --set-

env=MYSQL_ROOT_PASSWORD=password --set-env=MYSQL_USER=admin --set-
env=MYSQL_DATABASE=wordpress”
Figura 17. download image mysql (Elaboración propia)
Figura 18. running mysql image (Elaboración propia)
30
5.3 Apache
En este apartado nos descargaremos la imagen de Apache y la iniciaremos:
“rkt --insecure-options=image run Docker://firespring/apache2-php”
Figura 19. download apache image (Elaboración propia)
5.4 Proyecto en Wordpress
En este apartado nos descargaremos la imagen de wordpress y la iniciaremos:
“rkt --insecure-options=image run Docker://wordpress”
Figura 20. download Wordpress image (Elaboración propia)
31
Figura 21. running wordpress image (Elaboración propia)
Figura 22. Probando Wordpress en el navegador (Elaboración propia)
Figura 23. Configurando Wordpress (Elaboración propia)
32
6 CONCLUSIONES
dependencias para que sean fácilmente implementables y actualizables. El beneficio del uso de
los contenedores es que gracias a su naturaleza aislada, un administrador no tiene que
preocuparse de que cada aplicación o servicio interfiera o se afecte entre sí, además de ser muy
rentables ya que eliminan el costo del hardware de la ecuación. Los contenedores están
configurados para funcionar realizando el trabajo en una arquitectura de múltiples contenedores
o clúster. En un clúster de contenedores, hay un único maestro, con los otros contenedores
relacionados designados como nodos donde las funciones del maestro es programar las cargas
de trabajo para los nodos, y también administrar su ciclo de vida y sus actualizaciones.
Rkt es una alternativa de contenedor ligera y segura a Docker que se construye en base a un
estándar de contenedor abierto conocido como “Contenedor de aplicaciones” o especificación
“appc” el cual permite que las imágenes de rkt se puedan transportar a través de muchos
sistemas de contenedores como Kurma, JetPack. Rkt la verificación de la firma la realiza de
forma predeterminada entonces tan pronto como se descarga una imagen del servidor, se
verifica de forma cruzada con la firma del editor para ver si se ha manipulado de alguna manera,
ademas ejecuta contenedores como usuarios sin privilegios, de modo que incluso si un usuario
se rompe, no pueden afectar a otros contenedores o tomar el control del servidor.
Como pudimos observar en el apartado “Servicios con Rocket Container” brindar servicios a
través de Rocket Container es completamente fácil y rápido, pudimos levantar prácticamente
Mysql, Apache, y Wordpress los cuales están en diferentes host y corriendo sin depender una
de la otra gracias a los beneficios que ofrece esta hermosa herramienta, incluso podemos ir un
poco más lejos pudiendo orquestarlos con rkt-compose atravez de un archivo rkt-
compose.yaml.
Si bien en esta monografía pudimos ver la gran facilidad con la que se puede escalar un servicio
con contenedores web sin afectar la calidad del servicio prestado, todavía le falta mucho por
desarrollarse y mejorar.
33
7 GLOSARIO
Unix:
Registrado oficialmente como UNIX®, es un sistema operativo portable, multitarea y multiusuario,

desarrollado en 1969 por un grupo de empleados de los laboratorios Bell de AT&T, entre los que
figuran Dennis Ritchie, Ken Thompson y Douglas McIlroy.
Docker:
Es un proyecto de código abierto que automatiza el despliegue de aplicaciones dentro

de contenedores de software, proporcionando una capa adicional de abstracción y
automatización de virtualización de aplicaciones en múltiples sistemas operativos.
CoreoOS:
Es un sistema operativo ligero de código abierto basado en el Kernel de Linux y diseñado para
proporcionar la infraestructura para los despliegues en clúster, mientras se centra en la
automatización, facilidad de despliegue de aplicaciones, seguridad, fiabilidad y escalabilidad.
Como sistema operativo, CoreOS ofrece sólo las funcionalidades mínimas necesarias para la
implementación de aplicaciones dentro de contenedores de software, junto con mecanismos
incorporados para el descubrimiento de servicios y el intercambio de configuración
Máquina Virtual:
En informática, una máquina virtual es un software que simula un sistema de computación y

puede ejecutar programas como si fuese una computadora real. Este software en un principio
fue definido como "un duplicado eficiente y aislado de una máquina física". La acepción del
término actualmente incluye a máquinas virtuales que no tienen ninguna equivalencia directa con
ningún hardware real.
Una característica esencial de las máquinas virtuales es que los procesos que ejecutan están
limitados por los recursos y abstracciones proporcionados por ellas. Estos procesos no pueden
escaparse de esta "computadora virtual".
Jail Chroot:
Chroot es un comando UNIX que permite ejecutar un proceso bajo un directorio raíz simulada,
de manera que el proceso no puede acceder a archivos fuera de ese directorio.
DNS: (Domain Name System o Sistema de Nombres de Dominio)
34
Es un sistema de nomenclatura jerárquico descentralizado para dispositivos conectados a redes

IP como Internet o una red privada. Este sistema asocia información variada con nombre de
dominio asignado a cada uno de los participantes. Su función más importante es "traducir"
nombres inteligibles para las personas en identificadores binarios asociados con los equipos
conectados a la red, esto con el propósito de poder localizar y direccionar estos equipos
mundialmente.
Servidor:
Un servidor es una aplicación en ejecución capaz de atender las peticiones de un cliente y

devolverle una respuesta en concordancia. En la mayoría de los casos una misma computadora
puede proveer múltiples servicios y tener varios servidores en funcionamiento. La ventaja de
montar un servidor en computadoras dedicadas es la seguridad. Por esta razón la mayoría de
los servidores son procesos diseñados de forma que puedan funcionar en computadoras de
propósito específico.
VPS:
Un servidor virtual privado (VPS, del inglés virtual private server) es un método de particionar
un servidor físico en varios servidores virtuales (máquinas virtuales con tareas de servidor) de tal
forma que todo funcione como si se estuviese ejecutando en una única máquina. Cada servidor
virtual es capaz de funcionar bajo su propio sistema operativo y además cada servidor puede ser
reiniciado de forma independiente.
LXC:
LXC (Linux Containers) Es una tecnología de virtualización en el nivel de sistema operativo (SO)
para Linux. LXCpermite que un servidor físico ejecute múltiples instancias de sistemas operativos
aislados, conocidos como Servidores Privados Virtuales (SPV o VPS en inglés) o Entornos
Virtuales (EV).
TI:
La tecnología de la información (TI) es la aplicación de ordenadores y equipos
de telecomunicación para almacenar, recuperar, transmitir y manipular datos, con frecuencia
utilizado en el contexto de los negocios u otras empresas. El término es utilizado como sinónimo
para los computadores, y las redes de computadoras, pero también abarca otras tecnologías de
distribución de información, tales como la televisión y los teléfonos.
35
OpenVz:
Es una tecnología de virtualización en el nivel de sistema operativo para Linux. OpenVZ permite
que un servidor físico ejecute múltiples instancias de sistemas operativos aislados, conocidos
como Servidores Privados Virtuales (SPV o VPS en inglés) o Entornos Virtuales (EV).
Microservicio:
En una arquitectura de microservicios, los servicios son pequeños e independientes y están

acoplados de forma flexible. Cada servicio es un código base independiente, que puede
administrarse por un equipo de desarrollo pequeño. Los servicios pueden implementarse de
manera independiente.
Kubernetes:
Es un sistema de código libre para la automatización del despliegue, ajuste de escala y manejo
de aplicaciones en contenedores que fue originalmente diseñado por Google y donado a la Cloud
Native Computing Foundation (parte de la Linux Foundation). Soporta diferentes ambientes para
la ejecución de contenedores, incluido Docker.
Fundación OCI:
La Open Cloud Iniciative es una asociación que promueve la adopción de principios comunes de
servicios de nube abiertas para impulsar su estandarización y apertura real.
Host:
El término host o anfitrión se usa en informática para referirse a las computadoras u otros
dispositivos conectados a una red que proveen y utilizan servicios de ella. Los usuarios deben
utilizar anfitriones para tener acceso a la red. En general, los anfitriones son computadores
monousuario o multiusuario que ofrecen servicios de transferencia de archivos, conexión remota,
servidores de base de datos, servidores web, etc.
HTTP:
El Protocolo de transferencia de hipertexto (en inglés: Hypertext Transfer Protocol o HTTP) es el

protocolo de comunicación que permite las transferencias de información en la World Wide Web.
Hypervisor:
Un hipervisor (en inglés hypervisor) o monitor de máquina virtual (virtual machine monitor) es una
36
plataforma que permite aplicar diversas técnicas de control de virtualización para utilizar, al
mismo tiempo, diferentes sistemas operativos en una misma computadora.
Kernel:
Un núcleo o Kernel (de la raíz germánica Kern, núcleo, hueso) es un software que constituye una
parte fundamental del sistema operativo, y se define como la parte que se ejecuta en modo
privilegiado (conocido también como modo núcleo). Es el principal responsable de facilitar a los
distintos programas acceso seguro al hardware de la computadora o en forma básica, es el
encargado de gestionar recursos, a través de servicios de llamada al sistema.
Proyecto Debian:
Debian o Proyecto Debian es una comunidad conformada por desarrolladores y usuarios, que
mantiene un sistema operativo GNU basado en software libre. El sistema se encuentra pre-
compilado, empaquetado y en formato deb para múltiples arquitecturas de computador y para
varios núcleos.
TCP:
Protocolo de control de transmisión (en inglés Transmission Control Protocol o TCP), es uno de
los protocolos fundamentales en Internet. Muchos programas dentro de una red de datos
compuesta por redes de computadoras usan TCP para crear “conexiones” entre sí a través de
las cuales puede enviarse un flujo de datos. El protocolo garantiza que los datos serán
entregados en su destino sin errores y en el mismo orden en que se transmitieron.
Red Hat:
Red Hat, Inc. es una multinacional americana de software que provee software de código abierto
principalmente a empresas. Red Hat es conocida en gran medida por su sistema operativo
empresarial Red Hat Enterprise Linux y por la adquisición del proveedor de middleware
empresarial de código abierto JBoss. Red Hat también ofrece Red Hat Virtualization (RHV), un
producto de virtualización empresarial. Red Hat proporciona almacenamiento, plataformas de
sistemas 8 BIBLIOGRAFÍA
cloudtweaks. (2015, 11 3). cloudtweaks. Retrieved from

https://cloudtweaks.com/2015/03/docker-vs-rocket-container-technology/.
37
campusMVP. (9 de 10 de 2018). campusmvp. Obtenido de campusmvp:

https://www.campusmvp.es/recursos/post/los-beneficios-de-utilizar-docker-y-contenedores-a-la-
hora-de-programar.aspx
coreos. (1 de 7 de 2019). coreos. Obtenido de coreos:

https://coreos.com/rkt/docs/latest/distributions.html
coreos. (1 de 7 de 2019). coreos. Obtenido de coreos:

https://coreos.com/rkt/docs/latest/commands.html
coreos. (1 de 7 de 2019). coreos. Obtenido de coreos: https://coreos.com/rkt/docs/latest/getting-

started-guide.html
coreos. (1 de 7 de 2019). Obtenido de https://coreos.com/.
coreos. (1 de 7 de 2019). Obtenido de coreos: https://coreos.com/rkt/docs/latest/install-rkt-in-

coreos.html
Elasticsearch indexing. (2015). Publishing Ltd.
Gupta, Y. (2015). Kibana Essentials. Packt Publishing.
hoplasoftware. (2018, 10 1). hoplasoftware. Retrieved from https://hoplasoftware.com/una-

breve-historia-de-los-contenedores-desde-los-anos-70-a-docker-2016/
jgarzas. (24 de 7 de 2015). javiergarzas. Obtenido de javiergarzas:

https://www.javiergarzas.com/2015/07/que-es-docker-sencillo.html
Jonge, A. d. (11 de 7 de 2016). medium. Obtenido de medium:

https://medium.com/@adriaandejonge/moving-from-docker-to-rkt-310dc9aec938
Jonge, A. d. (11 de 7 de 2016). medium. Obtenido de medium:

https://medium.com/@adriaandejonge/moving-from-docker-to-rkt-310dc9aec938
Medico, Z. (31 de 05 de 2019). gentoo. Obtenido de gentoo:

https://packages.gentoo.org/packages/app-emulation/rkt
oblancarte. (7 de 3 de 2017). oscarblancarteblog. Obtenido de oscarblancarteblog:

https://www.oscarblancarteblog.com/2017/03/07/escalabilidad-horizontal-y-vertical/
38
RADU, G., MATTHEW, H. L., & ROY , R. (2016). Elasticsearch in action. Manning
Publications Co.
RAMÍREZ, I. (25 de 7 de 2016). xataka. Obtenido de xataka:

https://www.xataka.com/especiales/maquinas-virtuales-que-son-como-funcionan-y-como-
utilizarlas
Sudhi Seshachala, C. @. (3 de 11 de 2015). cloudtweaks. Obtenido de cloudtweaks:

https://cloudtweaks.com/2015/03/docker-vs-rocket-container-technology/
tecnologias-informacion. (1 de 1 de 2018). tecnologias-informacion. Obtenido de tecnologias-

informacion: https://www.tecnologias-informacion.com/contenedores.html
Team, B. C. (2018, 09 10). Spring Data Elasticsearch. Retrieved from

https://docs.spring.io/spring-data/elasticsearch/docs/3.0.10.RELEASE/reference/html/
TERRAZAS, G. R. (2018). CONTENEDORES DOCKER Y SU CAPACIDAD DE OFRECER

UNA RÁPIDA ESCALABILIDAD PARA SERVICIOS WEB. CBBA: Propia.
trusch. (15 de 6 de 2017). github. Obtenido de github: https://github.com/trusch/rkt-

compose/blob/master/README.md
trusch. (15 de 6 de 2017). github. Obtenido de github: https://github.com/trusch/rkt-

compose/blob/master/README.md
UpGuard. (1 de 11 de 2018). UpGuard . Obtenido de UpGuard :

https://www.upguard.com/articles/docker-vs-coreos
Visakh. (28 de 7 de 2016). bobcares. Obtenido de bobcares: https://bobcares.com/blog/docker-

vs-rkt-rocket/2/
Visakh. (28 de 7 de 2016). bobcares.com. Obtenido de bobcares:

https://bobcares.com/blog/docker-vs-rkt-rocket/1/
Visakh, S. (28 de 7 de 2016). bobcares. Obtenido de bobcares:

https://bobcares.com/blog/docker-vs-rkt-rocket/
39

Brindando Servicios Con Rocket Container

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Brindando Servicios Con Rocket Container

Загружено:

Авторское право:

Доступные форматы

UNIVERSIDAD MAYOR DE SAN SIMON

FACULTAD DE CIENCIAS Y TECNOLOGIA

“BRINDANDO SERVICIOS CON ROCKET

TRABAJO FINAL PRESENTADO PARA OBTENER EL

Postulante: MARCO ANTONIO CARRILLO PADILLA

Gracias a Dios por darme a mis padres y gracias a ello la vida.

No ha sido sencillo el camino hasta ahora, pero gracias a sus

A mi tutor Ing. Abel Raúl Díaz Castillo, por la colaboración que

A mis amigos que me ayudaron y apoyaron en los módulos de

5 SERVICIOS CON ROCKET CONTAINER 27

Figura 1. Historia de los contenedores (hoplasoftware, 2018) 6

Figura 2. CoreOS (cloudtweaks, 2015) Figura 3. Logo de Rocket (coreos, 2019) 9

Figura 4. Instalando rkt custom en Linux Container (coreos, 2019) 12

Figura 5. rkt empaquetado para gentoo (Medico, 2019) 14

Figura 6. Global Options (coreos, 2019) 17

Figura 7. fetching image redis (oblancarte, 2017) 21

Figura 8. Container image security (Visakh, 2016) 23

Figura 9. Verificación de la firma de la imagen (Visakh, 2016) 23

Figura 10. Preventing “root” privilege scalation attacks (Visakh, 2016) 24

Figura 11. Protocolo HTTPS utilizado por Rocket (Visakh, 2016) 25

Figura 12. Diferencia de Arquitectura (Jonge, 2016) 26

Figura 13. Ejemplo rkt-compose-yaml (trusch, github, 2017) 28

Figura 14. Configuracion de red “my-net” (Elaboración Propia) 28

Figura 15. Ejecutando rkt-compose.yaml (Elaboración propia) 29

Figura 16. Ejecución de pod (Elaboración propia) 30

Figura 17. download image mysql (Elaboración propia) 30

Figura 18. running mysql image (Elaboración propia) 30

Figura 19. download apache image (Elaboración propia) 31

Figura 20. download Wordpress image (Elaboración propia) 31

Figura 21. running wordpress image (Elaboración propia) 32

Figura 22. Probando Wordpress en el navegador (Elaboración propia) 32

Figura 23. Configurando Wordpress (Elaboración propia) 32

La presente monografía se centra en el estudio de las características de Rocket Container el cual

Se realizará una revisión bibliográfica de Rocket Container el mismo que en la actualidad es el

El desarrollo de software de aplicaciones web ha ido creciendo a pasos agigantados en los

El objetivo de la monografía es ver la facilidad con la que se brinda servicios y micro-servicios a

En la presente monografia se verá todas las características de rocket container desde su

1.1 Antecedentes Generales

En contraste, con la tecnología de contenedores, el servidor ejecuta un solo sistema operativo,

1.2 Antecedentes Específicos

Es totalmente evidente que Docker estaba en camino de convertirse en el estándar existente

Para el presente trabajo se utilizarán los siguientes métodos de investigación:

● Método Bibliográfico, debido a que se realizará la lectura y compilación de libros relacionados

Los contenedores han revolucionado el mundo de la implementación de aplicaciones y servicios

Figura 1. Historia de los contenedores (hoplasoftware, 2018)

3.1 Definición de Contenedores

La tecnología de contenedores, también conocida como solo un contenedor, es un método para

3.2 Importancia de los Contenedores

3.3 Funcionamiento de los Contenedores

La tecnología de contenedores no es un fenómeno nuevo, y ha sido durante mucho tiempo una

La ventaja de tener el programa como microservicios de componentes es que diferentes equipos

3.4 Gestión de los contenedores en las Empresas

Figura 2. CoreOS (cloudtweaks, 2015) Figura 3. Logo de Rocket (coreos, 2019)

Contrariamente al enfoque de Dockers, Rocket no involucra a un demonio exterior y estas

“Desde una perspectiva de seguridad y composabilidad, el modelo de proceso Docker, donde

RKT es un motor de contenedor de aplicaciones desarrollado para entornos de producción

RKT permite a los usuarios aplicar diferentes configuraciones (como parámetros de

RKT implementa un formato de contenedor moderno, abierto y estándar, la especificación de

Desde su introducción por CoreOS en diciembre de 2014, el proyecto rkt ha madurado

4.1 Instalación de Rocket

4.1.1 Instalación en Arco

rkt está disponible en el repositorio de la comunidad y se puede instalar utilizando pacman:

4.1.2 Instalación en CentOS

4.1.3 Instalación en Linux Container