Commit 2a00d04d authored by Carlos Viveros's avatar Carlos Viveros

Packer presentation first commit

parent 44189798
......@@ -154,6 +154,32 @@
<li>CI/CD: Al ser una herramienta que se utiliza por linea de comando nos permite integrarla en Procesos de integracion Continua </li>
</ul>
</section>
<section>
<h3>Como podes empezar con Packer?</h3>
<section id="fragments">
<p><span class="fragment">Instalar el binario: https://www.packer.io/downloads.html</span></p>
<p><span class="fragment">Crear un template.json</span></p>
<p><span class="fragment">Validar el template </span></p>
<p><span class="fragment">Crear la AMI</span></p>
<aside class="notes">
This slide has fragments which are also stepped through in the notes window.
</aside>
</section>
</section>
<section>
<h3>Como se compone un template?</h3>
<p><span class="fragment">La configuración de packer tiene diferentes secciones. </span></p>
<section id="fragments">
<h3>Builder</h3>
<p><span class="fragment">La unica seccion requerida es la de Builders, en donde se encuentran los bloques de configuracion para cada proveedor en donde quieres crear una ami</span></p>
<p><span class="fragment">Algunos ejemplos de builders: AWS AMI, GCEngine images, y VirtualBox.</span></p>
<p><span class="fragment">Tener en cuenta que se pueden tener multiples builders definidos por lo cual se pueden crear amis para diferentes proveedores</span></p>
<p><span class="fragment">Para amazon nosotros usamos: amazon-ebs</span></p>
<aside class="notes">
This slide has fragments which are also stepped through in the notes window.
</aside>
</section>
</section>
</section>
<section>
<section>
......@@ -243,13 +269,13 @@
<h2> Cosas que se aprendieron esa noche</h2>
<section>
<ul>
<li>No dar nada por sentado</li>
<li>Verificar que todo codigo necesario para una migración en un gitlab se encuentre en resguardo en otro lugar</li>
<li>A una tarea tan compleja y critica como lo es una migración a nivel infrastructura no se le debe estimar tan poco tiempo </li>
<li>Tener en cuenta cada componente de la arquitectura y conocer su impacto ante un downtime. Ej: Registro de imagenes docker</li>
<li>Mentalizarse que siempre algo puede salir mal y mantener la tranquilidad para resolverlo</li>
<li>No dar nada por sentado</li>
<li>Verificar que todo codigo necesario para una migración en un gitlab se encuentre en resguardo en otro lugar</li>
<li>A una tarea tan compleja y critica como lo es una migración a nivel infrastructura no se le debe estimar tan poco tiempo </li>
<li>Tener en cuenta cada componente de la arquitectura y conocer su impacto ante un downtime. Ej: Registro de imagenes docker</li>
<li>Mentalizarse que siempre algo puede salir mal y mantener la tranquilidad para resolverlo</li>
</ul>
</section>
</section>
</section>
<section>
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment