|
12 | 12 |
|
13 | 13 | > **El entorno está preparado para funcionar tanto en docker(Recomendado) en local o con una maquina virtual vagrant** |
14 | 14 |
|
| 15 | +> **Importante** - Esta configuración está destinada únicamente para entornos de desarrollo. No debe ser utilizada como referencia en un entorno productivo. |
| 16 | +
|
15 | 17 | ## Versiones de software |
16 | 18 | ### Entorno Docker (Recomendado) |
17 | 19 | - Docker Engine: >= 20 |
18 | | -- [Docker Compose plugin](https://docs.docker.com/compose/install/) |
19 | 20 |
|
20 | 21 | ### Entorno Vagrant |
21 | 22 | - Vagrant: >= 2.2.x |
@@ -97,179 +98,139 @@ bootcampVM: URL: https://vagrantcloud.com/ubuntu/jammy64 |
97 | 98 | ``` |
98 | 99 |
|
99 | 100 | 3. Añadimos entrada al fichero hosts la entrada -> <Direccion_ip_local> gitlab.local |
| 101 | +>**Nota Importante**: Si usamos vagrant la ip sera la de la maquina virtual -> 192.168.56.150 |
100 | 102 |
|
101 | 103 | * Linux en el fichero /etc/hosts |
102 | 104 |
|
103 | 105 | * Windows en el fichero c:\windows\system32\drivers\etc\hosts |
104 | 106 |
|
105 | | -## Un poco de arquitectura |
106 | | - |
107 | | - |
108 | | - |
109 | | -- Gitlab |
110 | | - |
111 | | -- Gitlab Runner(https://docs.gitlab.com/runner/#runner-execution-flow) |
112 | | - |
113 | | -- Gitlab Runner Executors(https://docs.gitlab.com/runner/executors/) |
114 | | - |
115 | | -- CI/CD Architecture  |
116 | | - |
117 | 107 | ## ¿Qué vamos a aprender? |
118 | 108 |
|
119 | 109 | 1. Conceptos Gitlab |
120 | 110 |
|
121 | 111 | - ¿Qué es Gitlab? |
122 | | - |
| 112 | + |
| 113 | + GitLab es una plataforma completa de DevOps que cubre todo el ciclo de vida del desarrollo de software, desde la planificación hasta la implementación. Ofrece un lugar centralizado donde los equipos pueden gestionar el código fuente, realizar pruebas, automatizar el despliegue y mucho más. |
| 114 | + - [Gitlab Architecture](https://docs.gitlab.com/ee/development/architecture.html) |
| 115 | + |
123 | 116 | - ¿Qué es un runner? |
124 | | - |
| 117 | + |
| 118 | + Un GitLab Runner es una aplicación que ejecuta los trabajos de un pipeline dentro de un proyecto de GitLab. En otras palabras, los runners son los encargados de ejecutar el código o las tareas definidas en el pipeline de un proyecto. GitLab Runner puede ejecutarse en diversos entornos, como servidores físicos, virtuales, en contenedores Docker, entre otros. |
| 119 | + - [Gitlab Runner Executors](https://docs.gitlab.com/runner/executors/) |
| 120 | + - [Gitlab Runner Execution Flow](https://docs.gitlab.com/runner/#runner-execution-flow) |
| 121 | + |
125 | 122 | - ¿Qué es un pipeline? |
126 | 123 |
|
| 124 | + Un pipeline en GitLab (y en el contexto de la integración continua y entrega continua, CI/CD) es un conjunto de tareas o trabajos automatizados que se ejecutan de manera secuencial o paralela para llevar a cabo una serie de procesos durante el desarrollo de un software. |
| 125 | + |
127 | 126 | 2. Gestión de Usuarios |
128 | 127 |
|
129 | 128 | - Alta de usuarios |
130 | | - |
131 | 129 | - Impersonate |
132 | | - |
133 | 130 | - SSH Keys |
134 | | - |
135 | 131 | - Access Token |
136 | 132 |
|
137 | | -3. Gestión de proyectos(repositorios) |
| 133 | +3. Gestión de proyectos(repositorios) y grupos: |
138 | 134 |
|
139 | | - - Miembros del proyecto |
140 | | - |
141 | | - - Deploy Tokens |
142 | | - |
143 | | - - Deploy Keys |
144 | | - |
145 | | - - Protected Branches |
146 | | - |
147 | | - - Protected TAGS |
| 135 | + - Miembros - [Roles and permissions](https://docs.gitlab.com/ee/user/permissions.html) |
| 136 | + - [Project Access Tokens](https://docs.gitlab.com/ee/user/project/settings/project_access_tokens.html) |
| 137 | + - [Group Access Tokens](https://docs.gitlab.com/ee/user/group/settings/group_access_tokens.html) |
| 138 | + - [Deploy Tokens](https://docs.gitlab.com/ee/user/project/deploy_tokens/) |
| 139 | + - [Deploy Keys](https://docs.gitlab.com/ee/user/project/deploy_keys/) |
| 140 | + - [Protected Branches](https://docs.gitlab.com/ee/user/project/repository/branches/protected.html) |
| 141 | + - [Protected Tags](https://docs.gitlab.com/ee/user/project/protected_tags.html) |
148 | 142 |
|
149 | 143 | 4. Entendiendo los pipelines |
150 | 144 |
|
151 | 145 | - Conceptos de Pipeline |
152 | | - |
153 | | - - ¿Qué es un pipeline? |
154 | | - |
155 | 146 | - ¿Como se define? |
156 | | - |
157 | | - - ¿Cuando se ejecuta? |
158 | | - |
| 147 | + |
| 148 | + Todas estas tareas estan definidas en un archivo de configuración llamado .gitlab-ci.yml. |
| 149 | + - [Referencia configuración de pipeline](https://docs.gitlab.com/ee/ci/yaml/) |
| 150 | + |
| 151 | + - ¿Cuando se ejecuta? https://docs.gitlab.com/ee/ci/pipelines/ |
| 152 | + |
| 153 | + - Branch pipelines |
| 154 | + - Merge request pipeline |
| 155 | + - Tag pipeline |
| 156 | + - Scheduled pipeline |
| 157 | + - Parent-child pipeline |
| 158 | + - Multi-project pipeline |
| 159 | + |
| 160 | + - ¿Qué es un job? |
| 161 | + |
| 162 | + Los jobs son las tareas concretas que se ejecutan dentro de cada stage. |
| 163 | + |
159 | 164 | - ¿Qué es un stage? |
160 | | - |
161 | | - - ¿Qué es un Job? |
| 165 | + |
| 166 | + Es un nivel o fase dentro del pipeline que agrupa jobs relacionados entre sí y permite que estos se ejecuten en un orden específico. |
162 | 167 |
|
163 | | -- Herramientas para crear pipelines |
| 168 | +- Editores |
| 169 | + - PipeLine Editor |
164 | 170 |
|
| 171 | + El Pipeline Editor de GitLab es una herramienta visual basada en la web que facilita la creación y gestión de pipelines de integración y entrega continua (CI/CD). Permite a los usuarios diseñar y configurar pipelines de manera intuitiva, sin tener que escribir manualmente los archivos de configuración en YAML. Con este editor, es posible definir las etapas, trabajos y otros aspectos de los pipelines de forma visual, validando la configuración en tiempo real para evitar errores. |
165 | 172 | - Web IDE |
166 | 173 |
|
167 | | - - PipeLine Editor |
168 | | - |
169 | | -- Estructura básica |
| 174 | + El Web IDE de GitLab es una herramienta de desarrollo totalmente basada en la web que permite a los usuarios escribir, modificar y gestionar su código directamente en GitLab, sin la necesidad de contar con un editor de código o IDE instalado en su equipo. |
170 | 175 |
|
| 176 | +[Referencia configuración de pipeline](http://gitlab.local:8888/help/ci/yaml/index) |
| 177 | +- Estructura básica de un pipeline |
| 178 | + - default |
171 | 179 | - image |
172 | | - |
173 | | - - job |
174 | | - |
175 | 180 | - stage |
176 | | - |
177 | 181 | - script |
178 | | - |
179 | 182 | - before_script |
180 | | - |
| 183 | + - after_script |
| 184 | + |
181 | 185 | - Variables de grupo, proyecto y pipeline |
182 | | - |
183 | | - - Variables predefinidas |
184 | | - |
| 186 | + - [Variables Predefinidas](https://docs.gitlab.com/ee/ci/variables/predefined_variables.html) |
185 | 187 | - Usando variables |
186 | | - |
187 | 188 | - Orden de precedencia |
188 | | - |
189 | 189 | - Casos de uso |
190 | 190 |
|
191 | 191 | - Control sobre los pipelines |
192 | | - |
193 | | - - Condicionales when y only |
194 | | - |
195 | | - - Condicionales avanzados con rules |
196 | | - |
197 | | - - Control de errores |
| 192 | + - Workflows |
| 193 | + - Rules |
| 194 | + - Allow failure |
| 195 | + - Needs |
198 | 196 |
|
199 | 197 | - Artifacts |
200 | 198 |
|
201 | | - - ¿Qué es un artifact? |
202 | | - |
203 | | - - ¿Para que lo usamos? |
204 | | - |
205 | | - - Casos de uso |
| 199 | +- Cache |
206 | 200 |
|
207 | 201 | - Environments |
208 | | - |
209 | 202 | - ¿Qué es un environment? |
210 | | - |
211 | 203 | - ¿Para que lo usamos? |
212 | | - |
213 | 204 | - Redeploy |
214 | | - |
215 | 205 | - Rollback |
216 | 206 |
|
217 | | -- Workflows |
| 207 | +- Services |
218 | 208 |
|
219 | | -5. Creacion de pipelines de build,test y deploy |
| 209 | +5. Uso de container registry y dependency proxy |
220 | 210 |
|
221 | | -6. Uso de container registry |
222 | | - |
223 | | - - ¿Qué es un container registry? |
224 | | - |
225 | | - - Repositando nuestra imágenes |
| 211 | + - ¿Qué es el container registry?, ¿y cómo se usa? |
| 212 | + - ¿Qué es el dependency proxy?, ¿y cómo se usa? |
226 | 213 |
|
227 | | -8. Pipelines de creación de imagenes Base |
| 214 | +6. Creacion de pipelines de build,test, deploy y release |
| 215 | + - App python con flask |
| 216 | + - App springboot |
228 | 217 |
|
229 | | -9. Usar nuestras Imágenes |
| 218 | +7. Downstream pipelines |
| 219 | + - Multi-project pipelines |
| 220 | + - Parent-child pipelines |
230 | 221 |
|
231 | | -10. Gitlab Pages |
| 222 | +8. Gitlab Pages |
232 | 223 |
|
233 | | -11. Bonus |
234 | | - |
235 | | - - Releases |
236 | | - |
237 | | - - Optimizando pipelines con Templates |
238 | | - |
239 | | - - Triggers |
240 | | - |
241 | | -## Cheatsheet |
242 | | - |
243 | | -### [Variables Predefinidas](http://gitlab.local:8888/help/ci/variables/predefined_variables.md) |
244 | | - |
245 | | -### [Referencia configuración de pipeline](http://gitlab.local:8888/help/ci/yaml/index) |
| 224 | +9. Optimizando pipelines con Templates |
| 225 | + - Anchors |
| 226 | + - Extends |
| 227 | + - Reference Tags |
| 228 | + - includes |
246 | 229 |
|
247 | 230 | ## Información usada en la Clase |
248 | 231 |
|
249 | | -### Gestion de Usuarios |
250 | | - |
251 | 232 | - User: **root**, Pass: **Gitl@bPass** , Access Level: **Admin** (Usuario ya creado) |
252 | 233 |
|
253 | 234 | - User: **developer1**, Pass: **dev€loper1** , Access Level: **Regular** |
254 | 235 |
|
255 | 236 | - User: **developer2**, Pass: **dev€loper2** , Access Level: **Regular** |
256 | | - |
257 | | -### [Roles]( http://gitlab.local:8888/help/user/permissions) |
258 | | - |
259 | | -- Guest |
260 | | - |
261 | | -- Reporter |
262 | | - |
263 | | -- Developer |
264 | | - |
265 | | -- Maintainer |
266 | | - |
267 | | -- Owner |
268 | | - |
269 | | -### [Visibilidad de grupos y proyectos](http://gitlab.local:8888/help/public_access/public_access.md) |
270 | | - |
271 | | -- **Private**: El grupo y sus proyectos sólo pueden ser vistos por los miembros. |
272 | | - |
273 | | -- **Internal**: El grupo y los proyectos internos pueden ser vistos por cualquier usuario conectado, excepto los usuarios externos. |
274 | | - |
275 | | -- **Public**: El grupo y los proyectos públicos pueden verse sin necesidad de autenticación. |
0 commit comments