{"id":3150,"date":"2021-04-19T08:22:31","date_gmt":"2021-04-19T06:22:31","guid":{"rendered":"https:\/\/inlab.fib.upc.edu\/?p=3150"},"modified":"2023-10-23T18:00:52","modified_gmt":"2023-10-23T16:00:52","slug":"devops-ejemplo-de-como-efectuar-un-despliegue-continuo","status":"publish","type":"post","link":"https:\/\/inlab.fib.upc.edu\/es\/articulos\/devops-ejemplo-de-como-efectuar-un-despliegue-continuo","title":{"rendered":"DevOps: Ejemplo de como efectuar un Despliegue Continuo"},"content":{"rendered":"<p>El despliegue continuo es una de las herramientas que nos facilita <em>DevOps<\/em> donde nosotros como desarrollador queremos controlar el proceso de desplegado de la APP que estamos desarrollando. Por lo tanto, en este ejemplo partimos de la base que ya tenemos una aplicaci\u00f3n&nbsp; (o cuando menos est\u00e1 en desarrollo) y queremos que esta aplicaci\u00f3n pueda ser desplegada por nosotros mismos y de forma autom\u00e1tica.<\/p>\n<p>Cuando hablamos de <em>CD<\/em> en en torno a <em>DevOps<\/em> tiene dos posibles significados:<\/p>\n<ul>\n<li>Entrega Contin\u00faa (<em>Continuos Delivery<\/em>): se construye el paquete y se deja a punto de ser desplegado, pero el despliegue se hace manual<\/li>\n<li>Despliegue Continuo (<em>Continuos Deployment<\/em>): el despliegue tambi\u00e9n se hace de forma automatizada.<\/li>\n<\/ul>\n<p>Antes de empezar con la configuraci\u00f3n hace falta que nos situamos en el entorno que nosotros tenemos para poder hacer el despliegue. En este caso el en torno al que disponemos es <strong>gitlbab + kubernetes<\/strong>. Este entorno consta de uno en torno a <em>PRE<\/em>&nbsp;y uno en torno a <em>PRO<\/em>. En este art\u00edculo queremos explicar c\u00f3mo desplegar de forma autom\u00e1tica en el entorno de PRE.<\/p>\n<p>El primero que hace falta es pedir alta del servicio y, una vez hecha los tr\u00e1mites pertinentes, recibimos como respuesta una serie de par\u00e1metros de configuraci\u00f3n que hay que a\u00f1adir al gitlab. Por eso entraremos a gitlab y la barra de la izquierda vayamos a &nbsp;<em>SETTINGS -&gt; CI\/CD<\/em>.<\/p>\n<p><img fetchpriority=\"high\" decoding=\"async\" class=\" size-full wp-image-3131\" alt=\"\" src=\"https:\/\/inlab.fib.upc.edu\/wp-content\/uploads\/2021\/04\/abril1.png\" style=\"width: 960px; height: 258px;\" width=\"960\" height=\"258\" srcset=\"https:\/\/inlab.fib.upc.edu\/wp-content\/uploads\/2021\/04\/abril1.png 960w, https:\/\/inlab.fib.upc.edu\/wp-content\/uploads\/2021\/04\/abril1-300x81.png 300w, https:\/\/inlab.fib.upc.edu\/wp-content\/uploads\/2021\/04\/abril1-768x206.png 768w, https:\/\/inlab.fib.upc.edu\/wp-content\/uploads\/2021\/04\/abril1-370x99.png 370w\" sizes=\"(max-width: 960px) 100vw, 960px\" \/><\/p>\n<p>Ahora hacemos \u201c<em>expand<\/em>\u201d a las variables y \u201c<em>add value<\/em>\u201d y a\u00f1adimos los valores que nos han hecho llegar.<\/p>\n<p><img decoding=\"async\" class=\" size-full wp-image-3134\" alt=\"\" src=\"https:\/\/inlab.fib.upc.edu\/wp-content\/uploads\/2021\/04\/abril2.png\" style=\"width: 601px; height: 427px;\" width=\"601\" height=\"427\" srcset=\"https:\/\/inlab.fib.upc.edu\/wp-content\/uploads\/2021\/04\/abril2.png 601w, https:\/\/inlab.fib.upc.edu\/wp-content\/uploads\/2021\/04\/abril2-300x213.png 300w, https:\/\/inlab.fib.upc.edu\/wp-content\/uploads\/2021\/04\/abril2-370x263.png 370w\" sizes=\"(max-width: 601px) 100vw, 601px\" \/><\/p>\n<p>Estos valores configuran donde se encuentra nuestro \u201c<em>artifactory<\/em>\u201d (lugar donde dejaremos las&nbsp; im\u00e1genes de nuestra app) y con qu\u00e9 usuario y contrase\u00f1a accederemos.<\/p>\n<p>Tambi\u00e9n configuramos&nbsp; <em>API<\/em> &nbsp;y lo <em>TOKEN<\/em> &nbsp;del <em>RUNDECK<\/em> (consola para la automatizaci\u00f3n de tareas que se accede v\u00eda <em>API<\/em>)<\/p>\n<p>Llegados en este punto ya tenemos entorno preparado para poder empezar con el CD. En el caso de gitlab todo lo en lo referente a CI\/CD&nbsp; pasa por el fichero de configuraci\u00f3n denominado <strong>.gitlab-*ci.yml<\/strong><\/p>\n<p>Una primera versi\u00f3n de este fichero ser\u00e1 la siguiente:<\/p>\n<p><span style=\"font-size:12px;\"><img decoding=\"async\" class=\" size-full wp-image-3137\" alt=\"\" src=\"https:\/\/inlab.fib.upc.edu\/wp-content\/uploads\/2021\/04\/11.png\" style=\"width: 561px; height: 357px;\" width=\"561\" height=\"357\" srcset=\"https:\/\/inlab.fib.upc.edu\/wp-content\/uploads\/2021\/04\/11.png 561w, https:\/\/inlab.fib.upc.edu\/wp-content\/uploads\/2021\/04\/11-300x191.png 300w, https:\/\/inlab.fib.upc.edu\/wp-content\/uploads\/2021\/04\/11-370x235.png 370w\" sizes=\"(max-width: 561px) 100vw, 561px\" \/><\/span><\/p>\n<p>Fij\u00e9monos que definimos 3 etapas (maceta, <em>build_*pre y deploy_*pre<\/em>)<\/p>\n<p>En este art\u00edculo no haremos referencia en la etapa de maceta, puesto que se trata de ejecutar todo aquello que hay que hacer para verificar que nuestra app funciona.<\/p>\n<p>El <em>build_*pre<\/em>el que hace es construye las im\u00e1genes <em>docker<\/em> de nuestra app (tenemos que tener un fichero <em>DOCKERFILE<\/em>&nbsp; en nuestro repositorio donde explicitamos como se tienen que construir cada una de las im\u00e1genes del proyecto).<\/p>\n<p>En el caso este del ejemplo en cuesti\u00f3n, nuestra APP estaba formada por <em>BD+ API+UI.<\/em> La base de datos como que era imagen docker por defecto no hac\u00eda falta que la construy\u00e9ramos por lo tanto el que basura es:<\/p>\n<ul>\n<li>Construimos las im\u00e1genes que s\u00ed que nos hacen falta (<em>API y UI<\/em>).<\/li>\n<li>Nos autenticamos contra el <em>arifactory<\/em>.<\/li>\n<li>Hagamos push de las im\u00e1genes que hemos creado.<\/li>\n<\/ul>\n<p>&nbsp;<\/p>\n<p>Antes de seguir dejadme hacer una breve explicaci\u00f3n del funcionamiento del&nbsp; <strong>.gitlab-*ci.yml<\/strong><\/p>\n<p>Nosotros como desarrolladores hacemos a menudo: <strong>git push origin master<\/strong> para subir el c\u00f3digo al repositorio, si tenemos el fichero <strong>.gitlab-*ci.yml<\/strong> muy configurado a cada push ejecutar\u00e1 la etapa de maceta, pero no ejecutar\u00e1 las otras etapas (por no hacer un CD cada vez que hagamos un push)<\/p>\n<p>Cuando&nbsp; nosotros decidimos que queremos hacer una imagen nueva de nuestra app tendremos que ejecutar los pedidos siguientes:<\/p>\n<ul>\n<li><strong><em>git push origin master<\/em><\/strong> (comprobamos que no hemos roto nada)<\/li>\n<li><strong><em>git tag &lt;num_versi\u00f3n&gt;<\/em><\/strong><\/li>\n<li><strong><em>git push \u2013tags <\/em><\/strong><\/li>\n<\/ul>\n<p>Este comportamiento que la etapa de <em>build_*pre y deploy_*pre<\/em>&nbsp; , que solo se hagan cuando basura un tag, lo configuramos con las l\u00edneas &nbsp;siguientes dentro de&nbsp; las etapas de <em>build_*pre y deploy_*pre<\/em>:<\/p>\n<p><img loading=\"lazy\" decoding=\"async\" class=\" size-full wp-image-3140\" alt=\"\" src=\"https:\/\/inlab.fib.upc.edu\/wp-content\/uploads\/2021\/04\/12.png\" style=\"width: 561px; height: 63px;\" width=\"561\" height=\"63\" srcset=\"https:\/\/inlab.fib.upc.edu\/wp-content\/uploads\/2021\/04\/12.png 561w, https:\/\/inlab.fib.upc.edu\/wp-content\/uploads\/2021\/04\/12-300x34.png 300w, https:\/\/inlab.fib.upc.edu\/wp-content\/uploads\/2021\/04\/12-370x42.png 370w\" sizes=\"(max-width: 561px) 100vw, 561px\" \/><\/p>\n<p>Si acab\u00e1ramos aqu\u00ed nuestro art\u00edculo el que habr\u00edamos hecho es <em>Contiuos Delvery<\/em>, tenemos las im\u00e1genes a punto de ser desplegadas, pero el desplegado se har\u00eda manualmente.<\/p>\n<p>Pero nosotros queremos ir m\u00e1s all\u00e1, queremos desplegar, por eso a\u00f1adimos en el nuestro <strong>.gitlab-*ci.yml<\/strong> en el apartado variable a\u00f1adimos todas las variables siguientes:<\/p>\n<p><img loading=\"lazy\" decoding=\"async\" class=\" size-full wp-image-3143\" alt=\"\" src=\"https:\/\/inlab.fib.upc.edu\/wp-content\/uploads\/2021\/04\/13.png\" style=\"width: 561px; height: 119px;\" width=\"561\" height=\"119\" srcset=\"https:\/\/inlab.fib.upc.edu\/wp-content\/uploads\/2021\/04\/13.png 561w, https:\/\/inlab.fib.upc.edu\/wp-content\/uploads\/2021\/04\/13-300x64.png 300w, https:\/\/inlab.fib.upc.edu\/wp-content\/uploads\/2021\/04\/13-370x78.png 370w\" sizes=\"(max-width: 561px) 100vw, 561px\" \/><\/p>\n<p>Y debajo de la etapa de <em>build_*pre<\/em> a\u00f1adimos etapa de <em>deploy_*pre:<\/em><\/p>\n<p><em><img loading=\"lazy\" decoding=\"async\" class=\" size-full wp-image-3146\" alt=\"\" src=\"https:\/\/inlab.fib.upc.edu\/wp-content\/uploads\/2021\/04\/14.png\" style=\"width: 561px; height: 258px;\" width=\"561\" height=\"258\" srcset=\"https:\/\/inlab.fib.upc.edu\/wp-content\/uploads\/2021\/04\/14.png 561w, https:\/\/inlab.fib.upc.edu\/wp-content\/uploads\/2021\/04\/14-300x138.png 300w, https:\/\/inlab.fib.upc.edu\/wp-content\/uploads\/2021\/04\/14-370x170.png 370w\" sizes=\"(max-width: 561px) 100vw, 561px\" \/><\/em><\/p>\n<p>El que basura con estas l\u00edneas es coger las im\u00e1genes de la <em>artefactory<\/em> y las copiamos al <em>RUNDECK<\/em> intermediando &nbsp;<em>API<\/em>, el <em>TOKEN<\/em> y lo <em>JOB_*ID<\/em> que hemos definido (unas cosas est\u00e1n el Settings del <em>gitlab<\/em> y lo <em>job<\/em> est\u00e1 a las variables del fichero .gitlab-*ci.yml).<\/p>\n<p>Si todo ha ido bien, llegados a este punto podemos acceder a nuestra APP (a la URL y puerto donde lo hemos definido) y podremos ver los <em>logs<\/em> de la <em>APP<\/em> mediante el <em>kibana<\/em>.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>El despliegue continuo es una de las herramientas que nos facilita DevOps donde nosotros como desarrollador queremos controlar el proceso de desplegado de la APP que estamos desarrollando. Por lo tanto, en este ejemplo partimos de la base que ya tenemos una aplicaci\u00f3n&nbsp; (o cuando menos est\u00e1 en desarrollo) y queremos que esta aplicaci\u00f3n pueda [&hellip;]<\/p>\n","protected":false},"author":594,"featured_media":3128,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[496],"tags":[],"experteses":[],"class_list":["post-3150","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-articulos"],"acf":[],"_links":{"self":[{"href":"https:\/\/inlab.fib.upc.edu\/es\/wp-json\/wp\/v2\/posts\/3150","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/inlab.fib.upc.edu\/es\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/inlab.fib.upc.edu\/es\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/inlab.fib.upc.edu\/es\/wp-json\/wp\/v2\/users\/594"}],"replies":[{"embeddable":true,"href":"https:\/\/inlab.fib.upc.edu\/es\/wp-json\/wp\/v2\/comments?post=3150"}],"version-history":[{"count":1,"href":"https:\/\/inlab.fib.upc.edu\/es\/wp-json\/wp\/v2\/posts\/3150\/revisions"}],"predecessor-version":[{"id":26427,"href":"https:\/\/inlab.fib.upc.edu\/es\/wp-json\/wp\/v2\/posts\/3150\/revisions\/26427"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/inlab.fib.upc.edu\/es\/wp-json\/wp\/v2\/media\/3128"}],"wp:attachment":[{"href":"https:\/\/inlab.fib.upc.edu\/es\/wp-json\/wp\/v2\/media?parent=3150"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/inlab.fib.upc.edu\/es\/wp-json\/wp\/v2\/categories?post=3150"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/inlab.fib.upc.edu\/es\/wp-json\/wp\/v2\/tags?post=3150"},{"taxonomy":"experteses","embeddable":true,"href":"https:\/\/inlab.fib.upc.edu\/es\/wp-json\/wp\/v2\/experteses?post=3150"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}