paramsx 2.2.0__tar.gz → 2.2.2__tar.gz
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- {paramsx-2.2.0 → paramsx-2.2.2}/CHANGELOG.md +35 -0
- {paramsx-2.2.0/paramsx.egg-info → paramsx-2.2.2}/PKG-INFO +107 -83
- {paramsx-2.2.0 → paramsx-2.2.2}/README.md +106 -82
- paramsx-2.2.2/paramsx/__init__.py +1 -0
- {paramsx-2.2.0 → paramsx-2.2.2}/paramsx/funcions.py +6 -6
- {paramsx-2.2.0 → paramsx-2.2.2}/paramsx/main.py +229 -73
- {paramsx-2.2.0 → paramsx-2.2.2}/paramsx/paramsx_config.py +10 -10
- {paramsx-2.2.0 → paramsx-2.2.2/paramsx.egg-info}/PKG-INFO +107 -83
- {paramsx-2.2.0 → paramsx-2.2.2}/setup.py +7 -1
- paramsx-2.2.0/paramsx/__init__.py +0 -0
- {paramsx-2.2.0 → paramsx-2.2.2}/LICENSE +0 -0
- {paramsx-2.2.0 → paramsx-2.2.2}/MANIFEST.in +0 -0
- {paramsx-2.2.0 → paramsx-2.2.2}/paramsx/text.py +0 -0
- {paramsx-2.2.0 → paramsx-2.2.2}/paramsx.egg-info/SOURCES.txt +0 -0
- {paramsx-2.2.0 → paramsx-2.2.2}/paramsx.egg-info/dependency_links.txt +0 -0
- {paramsx-2.2.0 → paramsx-2.2.2}/paramsx.egg-info/entry_points.txt +0 -0
- {paramsx-2.2.0 → paramsx-2.2.2}/paramsx.egg-info/requires.txt +0 -0
- {paramsx-2.2.0 → paramsx-2.2.2}/paramsx.egg-info/top_level.txt +0 -0
- {paramsx-2.2.0 → paramsx-2.2.2}/setup.cfg +0 -0
|
@@ -1,5 +1,40 @@
|
|
|
1
1
|
# Changelog
|
|
2
2
|
|
|
3
|
+
## 2.2.2
|
|
4
|
+
|
|
5
|
+
Un renombrado de la configuración, sin cambios de comportamiento. **Los nombres antiguos
|
|
6
|
+
se siguen aceptando**, así que no tienes que tocar tu fichero para actualizar.
|
|
7
|
+
|
|
8
|
+
### Cambiado
|
|
9
|
+
|
|
10
|
+
- **Un solo nombre para el concepto: `perfiles` / `perfil`.** El mismo concepto se llamaba de tres formas distintas: el diccionario era `naming`, la clave de cada entrada de `parameter_list` era `convencion` y la documentación decía "perfil". Explicárselo a alguien obligaba a traducir dos veces. Ahora:
|
|
11
|
+
|
|
12
|
+
| Antes | Ahora |
|
|
13
|
+
|---|---|
|
|
14
|
+
| `naming = {...}` | `perfiles = {...}` |
|
|
15
|
+
| `{"path": "/rds", "convencion": "min"}` | `{"path": "/rds", "perfil": "min"}` |
|
|
16
|
+
| `convencion_nuevos = "min"` | `perfil_nuevos = "min"` |
|
|
17
|
+
|
|
18
|
+
- `paramsx configure` te dice qué nombres antiguos usas y cómo se llaman ahora, incluidas las entradas de `parameter_list`. Los viejos (`naming`, `convencion`, `convencion_nuevos` y el `abac` de la 2.0) se traducen al cargar, así que dentro del programa solo existe el nombre nuevo.
|
|
19
|
+
|
|
20
|
+
## 2.2.1
|
|
21
|
+
|
|
22
|
+
Solo comandos de terminal y documentación: no cambia nada de la lectura, la carga ni la
|
|
23
|
+
construcción de rutas. Si ya tienes la 2.2.0 funcionando, actualizar no te obliga a tocar
|
|
24
|
+
tu configuración.
|
|
25
|
+
|
|
26
|
+
### Añadido
|
|
27
|
+
|
|
28
|
+
- **`paramsx --version`** (y `-v`), y la versión también en la cabecera de `paramsx --help`. La versión pasa a vivir en `paramsx/__init__.py` y `setup.py` la lee de ahí, para que el paquete y el comando no puedan decir cosas distintas.
|
|
29
|
+
- **`paramsx configure` sobre una configuración que ya existe ya no se queda en "no se sobrescribirá".** Sigue sin tocar el fichero, pero ahora te dice qué opciones nuevas no tienes y con qué valor por defecto se rellenan, si usas el nombre antiguo `abac`, y si la configuración es válida.
|
|
30
|
+
- **`paramsx configure --ejemplo`**: además de lo anterior, deja la plantilla de esta versión en `~/.xsoft/paramsx_config.ejemplo.py`, al lado de la tuya, para comparar. ParamsX no la lee: es solo referencia. Escribir en tu configuración es lo único que no se puede deshacer, así que va en un comando aparte y en otro fichero.
|
|
31
|
+
- Mensaje de primer arranque más claro cuando todavía no hay configuración, explicando qué hace `paramsx configure` y dónde va el fichero.
|
|
32
|
+
|
|
33
|
+
### Cambiado
|
|
34
|
+
|
|
35
|
+
- **`paramsx --help` al día.** La opción 2 ya explica que eliges entre los ficheros que tengas en el directorio; el ejemplo de `mixto` usa el entorno en mayúscula como el resto de la documentación; `fichero_por_ruta` enseña el nombre real (`parameters_dev__API_STA__max.py`); y se documentan `profile_name`, `region_name` y `entornos`, que no aparecían aunque son obligatorios.
|
|
36
|
+
- **El README muestra el contenido literal de `paramsx_config.py`**, con sus comentarios y tablas, en vez de una versión resumida: es exactamente lo que te crea `paramsx configure`, así que no pueden desincronizarse. Y una tabla con todos los comandos disponibles.
|
|
37
|
+
|
|
3
38
|
## 2.2.0
|
|
4
39
|
|
|
5
40
|
### Añadido
|
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
Metadata-Version: 2.4
|
|
2
2
|
Name: paramsx
|
|
3
|
-
Version: 2.2.
|
|
3
|
+
Version: 2.2.2
|
|
4
4
|
Summary: Librería para gestionar y respaldar parámetros de AWS SSM de manera sencilla y eficiente.
|
|
5
5
|
Home-page: https://github.com/pistatxos/paramsx
|
|
6
6
|
Author: Mariox
|
|
@@ -24,7 +24,7 @@ ParamsX es una herramienta diseñada para gestionar y organizar parámetros de A
|
|
|
24
24
|
|
|
25
25
|
## ⚠ Breaking change en la versión 2.0.0
|
|
26
26
|
|
|
27
|
-
Si vienes de la 1.x tienes que **actualizar a mano tu `~/.xsoft/paramsx_config.py`**: `parameter_list` ya no es una lista de strings, ahora cada entrada es un diccionario
|
|
27
|
+
Si vienes de la 1.x tienes que **actualizar a mano tu `~/.xsoft/paramsx_config.py`**: `parameter_list` ya no es una lista de strings, ahora cada entrada es un diccionario que declara su perfil. La versión antigua **no es compatible** y ParamsX se niega a arrancar mostrando cómo migrarla. Detalle completo en el [CHANGELOG](CHANGELOG.md).
|
|
28
28
|
|
|
29
29
|
### Estructura Recomendada
|
|
30
30
|
La convención de naming es de 5 niveles, donde los últimos segmentos son opcionales según el caso:
|
|
@@ -97,10 +97,10 @@ Esto te permitirá mantener respaldos seguros o realizar migraciones/reorganizac
|
|
|
97
97
|
|
|
98
98
|
4. Crear nuevo parámetro
|
|
99
99
|
- Crea un parámetro desde cero sin salir de la herramienta. Te pedirá, en este orden:
|
|
100
|
-
- La ruta **sin el entorno**, igual que la declaras en `parameter_list`: el perfil
|
|
100
|
+
- La ruta **sin el entorno**, igual que la declaras en `parameter_list`: el perfil se encarga de colocarlo. Verás en pantalla la ruta resultante en AWS antes de seguir.
|
|
101
101
|
- El valor: texto plano o JSON en una línea (por ejemplo `{"host": "x", "user": "y", "pass": "z"}`), que se valida antes de continuar.
|
|
102
102
|
- Las tags obligatorias, si tienes `tags_activas = True`.
|
|
103
|
-
- El perfil que se usa es el que declares en `
|
|
103
|
+
- El perfil que se usa es el que declares en `perfil_nuevos`. Si tu perfil es de tipo `mixto`, escribe el `*` en la ruta para indicar dónde va el entorno.
|
|
104
104
|
- Antes de subirlo verás una pantalla de confirmación con la ruta, el valor y las tags. El parámetro se crea con `Overwrite=False`, así que nunca machaca uno existente.
|
|
105
105
|
- Tras crearlo aparecerá la próxima vez que leas la ruta correspondiente de tu `parameter_list`.
|
|
106
106
|
|
|
@@ -128,12 +128,56 @@ Este comando creará automáticamente una carpeta de configuración en tu direct
|
|
|
128
128
|
|
|
129
129
|
Dentro de esta carpeta, encontrarás el archivo paramsx_config.py. Este archivo contiene la configuración inicial que debes ajustar según tu entorno.
|
|
130
130
|
|
|
131
|
+
Si ya tenías configuración de una versión anterior, `paramsx configure` **no la sobrescribe**: te dice qué opciones nuevas no tienes y con qué valor por defecto se están rellenando, y si la configuración es válida. Con `paramsx configure --ejemplo` además deja la plantilla de esta versión en `paramsx_config.ejemplo.py`, al lado de la tuya, para que compares sin tocar nada.
|
|
132
|
+
|
|
131
133
|
Ejemplo del contenido de paramsx_config.py:
|
|
132
134
|
|
|
133
135
|
```python
|
|
134
136
|
## Configuraciones ParamsX
|
|
135
137
|
|
|
136
|
-
|
|
138
|
+
# --- Perfiles -------------------------------------------------------------
|
|
139
|
+
# Un perfil dice CÓMO se construye la ruta real en AWS a partir de la ruta que declaras
|
|
140
|
+
# en 'parameter_list' y del entorno que eliges en el menú. Los nombres son tuyos: define
|
|
141
|
+
# solo los que uses y llámalos como quieras. Un perfil tiene tres campos:
|
|
142
|
+
#
|
|
143
|
+
# campo | valores | qué decide
|
|
144
|
+
# ------------------+------------------------------------------+---------------------------
|
|
145
|
+
# posicion_entorno | inicio | final | mixto | ninguno | dónde va el entorno
|
|
146
|
+
# case_entorno | lower | upper | capitalize | cómo se escribe el entorno
|
|
147
|
+
# case_ruta | lower | upper | capitalize | ninguno | case de la ruta AL CREAR
|
|
148
|
+
#
|
|
149
|
+
# posicion_entorno -> dónde se coloca el entorno (ejemplos con el entorno 'dev'):
|
|
150
|
+
#
|
|
151
|
+
# valor | ruta declarada | ruta real en AWS
|
|
152
|
+
# ---------+-----------------+--------------------------------------------------------
|
|
153
|
+
# inicio | /rds | /dev/rds
|
|
154
|
+
# final | /API/STA | /API/STA/DEV
|
|
155
|
+
# mixto | /API/*/STA | /API/DEV/STA el '*' marca el sitio; uno y como segmento
|
|
156
|
+
# ninguno | /api/sta/auth | /api/sta/auth una cuenta AWS por entorno; case_entorno da igual
|
|
157
|
+
#
|
|
158
|
+
# case_entorno -> cómo se escribe ese entorno en la ruta:
|
|
159
|
+
#
|
|
160
|
+
# valor | 'dev' se escribe | ruta real de /API/STA con posicion_entorno=final
|
|
161
|
+
# ------------+------------------+------------------------------------------------
|
|
162
|
+
# lower | dev | /API/STA/dev
|
|
163
|
+
# upper | DEV | /API/STA/DEV
|
|
164
|
+
# capitalize | Dev | /API/STA/Dev
|
|
165
|
+
#
|
|
166
|
+
# case_ruta -> a qué case se fuerza la ruta que TÚ escribes al CREAR un parámetro
|
|
167
|
+
# (opción 4 del menú). No afecta a leer ni a editar: lo que ya existe en AWS se
|
|
168
|
+
# respeta siempre tal cual esté.
|
|
169
|
+
#
|
|
170
|
+
# valor | si escribes /API/MULTIAPI/Token, se crea
|
|
171
|
+
# ------------+-----------------------------------------
|
|
172
|
+
# lower | /api/multiapi/token
|
|
173
|
+
# upper | /API/MULTIAPI/TOKEN
|
|
174
|
+
# capitalize | /Api/Multiapi/Token
|
|
175
|
+
# ninguno | /API/MULTIAPI/Token
|
|
176
|
+
#
|
|
177
|
+
# Combina los tres campos como necesites: no hay una lista cerrada de perfiles. En el
|
|
178
|
+
# README tienes más ejemplos.
|
|
179
|
+
|
|
180
|
+
perfiles = {
|
|
137
181
|
"min": {"posicion_entorno": "inicio", "case_entorno": "lower", "case_ruta": "lower"},
|
|
138
182
|
"max": {"posicion_entorno": "final", "case_entorno": "upper", "case_ruta": "ninguno"},
|
|
139
183
|
"mixto_max": {"posicion_entorno": "mixto", "case_entorno": "upper", "case_ruta": "ninguno"},
|
|
@@ -146,101 +190,71 @@ configuraciones = {
|
|
|
146
190
|
"region_name": "eu-south-2", # Cambiar por tu región de AWS
|
|
147
191
|
"entornos": ['dev', 'pre', 'prod'], # SIEMPRE en minúscula, es la lista canónica única
|
|
148
192
|
"parameter_list": [
|
|
149
|
-
{"path": "/common", "
|
|
150
|
-
{"path": "/rds", "
|
|
151
|
-
{"path": "/EMAIL", "
|
|
152
|
-
{"path": "/API/STA", "
|
|
153
|
-
|
|
193
|
+
{"path": "/common", "perfil": "min"}, # -> /dev/common
|
|
194
|
+
{"path": "/rds", "perfil": "min"}, # -> /dev/rds
|
|
195
|
+
{"path": "/EMAIL", "perfil": "max"}, # -> /EMAIL/DEV
|
|
196
|
+
{"path": "/API/STA", "perfil": "max"}, # -> /API/STA/DEV
|
|
197
|
+
# Con 'mixto' acotas por debajo del entorno: esto lee solo stan_ai, en vez de
|
|
198
|
+
# todo lo que cuelga de /API/MULTIAPI/DEV
|
|
199
|
+
{"path": "/API/MULTIAPI/*/stan_ai", "perfil": "mixto_max"}, # -> /API/MULTIAPI/DEV/stan_ai
|
|
154
200
|
]
|
|
155
201
|
}
|
|
156
202
|
|
|
157
|
-
|
|
203
|
+
# Perfil que se usa al crear un parámetro nuevo (opción 4 del menú).
|
|
204
|
+
# Si no lo defines, se usa el primero de 'perfiles'.
|
|
205
|
+
perfil_nuevos = "min"
|
|
158
206
|
|
|
207
|
+
# ¿El nombre del fichero exportado incluye la ruta leída?
|
|
208
|
+
# False -> parameters_dev.py (comportamiento de siempre)
|
|
209
|
+
# True -> parameters_dev__API_STA__max.py (uno por entrada y entorno: lleva el
|
|
210
|
+
# entorno, la ruta y el perfil, porque dos entradas pueden compartir ruta)
|
|
211
|
+
# Ponlo en True si sueles leer varias rutas del mismo entorno y no quieres que la
|
|
212
|
+
# segunda lectura te machaque el fichero de la primera.
|
|
159
213
|
fichero_por_ruta = False
|
|
160
214
|
|
|
161
215
|
|
|
162
216
|
## Configuraciones Tags
|
|
163
217
|
|
|
218
|
+
# Gestionar las tags de los parámetros: leerlas de AWS, exponerlas en el fichero
|
|
219
|
+
# exportado para editarlas y validar las obligatorias al cargar.
|
|
220
|
+
# True -> las tags viajan en el fichero y se validan.
|
|
221
|
+
# False -> no aparecen tags en el fichero y no se valida nada.
|
|
222
|
+
# En cuentas cuyo control de acceso va por tags (ABAC vía IAM) esto debe estar en True.
|
|
164
223
|
tags_activas = True
|
|
165
224
|
|
|
225
|
+
# Solo aplica si tags_activas = True.
|
|
226
|
+
# False -> validación bloqueante: si a un parámetro le falta alguna tag obligatoria
|
|
227
|
+
# no se sube (ni su valor ni sus tags).
|
|
228
|
+
# True -> se permiten vacías: el parámetro se sube igualmente y las tags sin valor
|
|
229
|
+
# simplemente NO se crean en AWS (no se suben como etiquetas vacías).
|
|
166
230
|
obligatorias_vacias = False
|
|
167
231
|
|
|
232
|
+
# Tags que se exigen en cada parámetro cuando tags_activas = True. La lista es libre:
|
|
233
|
+
# estas 8 son las que sostienen el control de acceso ABAC vía IAM de nuestra cuenta.
|
|
168
234
|
tags_obligatorias = [
|
|
169
|
-
"Application",
|
|
170
|
-
"
|
|
235
|
+
"Application",
|
|
236
|
+
"Environment",
|
|
237
|
+
"Owner",
|
|
238
|
+
"Project",
|
|
239
|
+
"Product",
|
|
240
|
+
"Service",
|
|
241
|
+
"Component",
|
|
242
|
+
"ManagedBy",
|
|
171
243
|
]
|
|
172
244
|
```
|
|
173
245
|
Nota: Si el archivo paramsx_config.py ya existe, no será sobrescrito durante la instalación para proteger las configuraciones personalizadas.
|
|
174
246
|
|
|
175
|
-
### Los perfiles
|
|
176
|
-
|
|
177
|
-
Cada organización nombra sus parámetros a su manera, así que ParamsX no impone ninguna convención: **tú defines los perfiles que uses en el diccionario `naming` y les pones el nombre que quieras**. Cada entrada de `parameter_list` declara con qué perfil se construye su ruta completa.
|
|
178
|
-
|
|
179
|
-
Un perfil tiene tres campos:
|
|
180
|
-
|
|
181
|
-
| Campo | Valores | Qué decide |
|
|
182
|
-
|---|---|---|
|
|
183
|
-
| `posicion_entorno` | `inicio` \| `final` \| `mixto` \| `ninguno` | Dónde va el entorno dentro de la ruta. |
|
|
184
|
-
| `case_entorno` | `lower` \| `upper` \| `capitalize` | Cómo se escribe el entorno. |
|
|
185
|
-
| `case_ruta` | `lower` \| `upper` \| `capitalize` \| `ninguno` | Case de la ruta al crear parámetros. |
|
|
186
|
-
|
|
187
|
-
Y en detalle:
|
|
188
|
-
|
|
189
|
-
**`posicion_entorno`** — dónde se coloca el entorno, con el entorno `dev`:
|
|
247
|
+
### Los perfiles
|
|
190
248
|
|
|
191
|
-
|
|
192
|
-
|---|---|---|---|
|
|
193
|
-
| `inicio` | `/rds` | `/dev/rds` | |
|
|
194
|
-
| `final` | `/API/STA` | `/API/STA/DEV` | |
|
|
195
|
-
| `mixto` | `/API/*/STA` | `/API/DEV/STA` | el `*` marca el sitio |
|
|
196
|
-
| `ninguno` | `/api/sta/auth` | `/api/sta/auth` | una cuenta AWS por entorno |
|
|
197
|
-
|
|
198
|
-
**`case_entorno`** — cómo se escribe ese entorno en la ruta:
|
|
199
|
-
|
|
200
|
-
| Valor | `dev` se escribe | `/API/STA` con `posicion_entorno: final` |
|
|
201
|
-
|---|---|---|
|
|
202
|
-
| `lower` | `dev` | `/API/STA/dev` |
|
|
203
|
-
| `upper` | `DEV` | `/API/STA/DEV` |
|
|
204
|
-
| `capitalize` | `Dev` | `/API/STA/Dev` |
|
|
205
|
-
|
|
206
|
-
**`case_ruta`** — a qué case se fuerza la ruta que escribes al **crear** un parámetro (opción 4). No afecta a leer ni a editar: lo que ya existe en AWS se respeta siempre tal cual esté.
|
|
207
|
-
|
|
208
|
-
| Valor | Si escribes `/API/MULTIAPI/Token`, se crea |
|
|
209
|
-
|---|---|
|
|
210
|
-
| `lower` | `/api/multiapi/token` |
|
|
211
|
-
| `upper` | `/API/MULTIAPI/TOKEN` |
|
|
212
|
-
| `capitalize` | `/Api/Multiapi/Token` |
|
|
213
|
-
| `ninguno` | `/API/MULTIAPI/Token` |
|
|
249
|
+
Cada organización nombra sus parámetros a su manera, así que ParamsX no impone ninguna convención: **tú defines los perfiles que uses en el diccionario `perfiles` y les pones el nombre que quieras**. Cada entrada de `parameter_list` declara con qué perfil se construye su ruta completa, con la clave `perfil`. Los tres campos de un perfil y sus valores están explicados en el propio fichero de configuración, ahí arriba.
|
|
214
250
|
|
|
215
251
|
**No hay una lista cerrada de perfiles.** Los tres campos se combinan libremente, así que la plantilla no intenta traértelos todos: define los dos o tres que use tu organización y olvídate del resto. `min` y `max` vienen predefinidos porque son los que ParamsX traía antes de que los perfiles fueran configurables.
|
|
216
252
|
|
|
217
|
-
|
|
253
|
+
**Para qué sirve el `*`.** Además de colocar el entorno donde quieras, acota la lectura a un solo subárbol: con `/API/MULTIAPI/*/stan_ai` lees únicamente `/API/MULTIAPI/DEV/stan_ai`, en vez de todo lo que cuelga de `/API/MULTIAPI/DEV`. Debe ser un segmento entero, aparecer **exactamente una vez** y solo se admite en perfiles `mixto`: si el perfil y la ruta no cuentan la misma historia, ParamsX te lo dice al arrancar en vez de leer una ruta inexistente y devolverte una lista vacía.
|
|
218
254
|
|
|
219
|
-
|
|
255
|
+
**Los entornos.** Ya no existe la lista `entornos_old`: el entorno sale siempre de la lista canónica `entornos` (en minúscula), aplicándole el `case_entorno` del perfil. Si en tus rutas se llama `staging` en vez de `pre`, ponlo así en `entornos`.
|
|
220
256
|
|
|
221
|
-
|
|
222
|
-
|
|
223
|
-
Ejemplo completo de una `parameter_list` real, mezclando perfiles:
|
|
224
|
-
|
|
225
|
-
```python
|
|
226
|
-
"parameter_list": [
|
|
227
|
-
{"path": "/common", "convencion": "min"},
|
|
228
|
-
{"path": "/rds", "convencion": "min"},
|
|
229
|
-
{"path": "/api", "convencion": "min"},
|
|
230
|
-
{"path": "/INFRA", "convencion": "max"},
|
|
231
|
-
{"path": "/API/STA", "convencion": "max"},
|
|
232
|
-
{"path": "/API/p15", "convencion": "max"},
|
|
233
|
-
{"path": "/API/MULTIAPI", "convencion": "max"},
|
|
234
|
-
{"path": "/APP/Alertas", "convencion": "max"},
|
|
235
|
-
{"path": "/BUCKETS", "convencion": "max"},
|
|
236
|
-
{"path": "/EMAIL", "convencion": "max"},
|
|
237
|
-
{"path": "/INFERENCIAS/TASA_DMI", "convencion": "max"},
|
|
238
|
-
{"path": "/CEE/CEXGEN", "convencion": "max"},
|
|
239
|
-
{"path": "/API/MULTIAPI/*/stan_ai", "convencion": "mixto_max"},
|
|
240
|
-
]
|
|
241
|
-
```
|
|
242
|
-
|
|
243
|
-
Sobre mayúsculas y minúsculas: ParamsX **no renombra ni fuerza el case de los parámetros que ya existen**, los lee y edita tal cual estén. El `case_ruta` del perfil solo entra en juego al crear parámetros nuevos.
|
|
257
|
+
Y ParamsX **no renombra ni fuerza el case de los parámetros que ya existen**: los lee y edita tal cual estén. El `case_ruta` del perfil solo entra en juego al crear parámetros nuevos.
|
|
244
258
|
|
|
245
259
|
### Un fichero por ruta: `fichero_por_ruta`
|
|
246
260
|
|
|
@@ -252,15 +266,15 @@ En el nombre van el entorno, la ruta y el perfil, porque dos entradas pueden com
|
|
|
252
266
|
|
|
253
267
|
| Entrada | Fichero |
|
|
254
268
|
|---|---|
|
|
255
|
-
| `{"path": "/API/STA", "
|
|
256
|
-
| `{"path": "/API/*/STA", "
|
|
269
|
+
| `{"path": "/API/STA", "perfil": "max"}` | `parameters_dev__API_STA__max.py` |
|
|
270
|
+
| `{"path": "/API/*/STA", "perfil": "mixto_max"}` | `parameters_dev__API_env_STA__mixto_max.py` |
|
|
257
271
|
|
|
258
272
|
### Cómo acotar tu parameter_list (recomendación)
|
|
259
273
|
|
|
260
274
|
`parameter_list` es solo tu vista de trabajo: **la seguridad real la impone IAM, no este fichero**. La recomendación de uso es:
|
|
261
275
|
|
|
262
|
-
- **Admins**: pueden configurar rutas raíz amplias, por ejemplo `{"path": "/rds", "
|
|
263
|
-
- **Usuarios normales**: conviene acotar la ruta a lo que su rol IAM tiene realmente autorizado, por ejemplo `{"path": "/rds/cee-dev/api", "
|
|
276
|
+
- **Admins**: pueden configurar rutas raíz amplias, por ejemplo `{"path": "/rds", "perfil": "min"}` → `/dev/rds`.
|
|
277
|
+
- **Usuarios normales**: conviene acotar la ruta a lo que su rol IAM tiene realmente autorizado, por ejemplo `{"path": "/rds/cee-dev/api", "perfil": "min"}` → `/dev/rds/cee-dev/api`.
|
|
264
278
|
|
|
265
279
|
Si configuras una ruta más amplia que tus permisos, no pasa nada grave: ParamsX te avisará con un mensaje claro de acceso denegado en vez de una traza de boto3. Pero afinar la ruta te ahorra el error.
|
|
266
280
|
|
|
@@ -342,7 +356,17 @@ En algunos sistemas (especialmente en entornos corporativos como Windows), el PA
|
|
|
342
356
|
```source ~/.zshrc # Para zsh```
|
|
343
357
|
|
|
344
358
|
Una vez instalado, verifica que el comando paramsx esté disponible ejecutando:
|
|
345
|
-
```paramsx --
|
|
359
|
+
```paramsx --version```
|
|
360
|
+
|
|
361
|
+
Comandos disponibles:
|
|
362
|
+
|
|
363
|
+
| Comando | Qué hace |
|
|
364
|
+
|---|---|
|
|
365
|
+
| `paramsx` | Abre el menú interactivo (necesita configuración). |
|
|
366
|
+
| `paramsx configure` | Crea la configuración la primera vez; si ya existe, la revisa sin tocarla. |
|
|
367
|
+
| `paramsx configure --ejemplo` | Además deja la plantilla de esta versión al lado, para comparar. |
|
|
368
|
+
| `paramsx --version` | Versión instalada. |
|
|
369
|
+
| `paramsx --help` | Ayuda, con el resumen de todas las opciones de configuración. |
|
|
346
370
|
|
|
347
371
|
|
|
348
372
|
## Modo de empleo
|
|
@@ -359,7 +383,7 @@ El programa mostrará un menú donde Podrás:
|
|
|
359
383
|
- Crear un parámetro nuevo.
|
|
360
384
|
|
|
361
385
|
### Leer Parámetros:
|
|
362
|
-
1. Selecciona la opción "Leer parámetros" en el menú. La lista muestra cada ruta con su perfil
|
|
386
|
+
1. Selecciona la opción "Leer parámetros" en el menú. La lista muestra cada ruta con su perfil, por ejemplo `/rds [min]` o `/API/STA [max]`.
|
|
363
387
|
2. Elige el prefijo y el entorno que deseas consultar.
|
|
364
388
|
3. Los parámetros serán descargados y guardados en archivos como:
|
|
365
389
|
- parameters_dev.py
|
|
@@ -380,7 +404,7 @@ El programa mostrará un menú donde Podrás:
|
|
|
380
404
|
|
|
381
405
|
### Crear un parámetro nuevo:
|
|
382
406
|
1. Selecciona la opción "Crear nuevo parámetro" y elige el entorno.
|
|
383
|
-
2. Escribe la ruta **sin el entorno**, como en tu `parameter_list`: ParamsX le aplica el perfil de `
|
|
407
|
+
2. Escribe la ruta **sin el entorno**, como en tu `parameter_list`: ParamsX le aplica el perfil de `perfil_nuevos` y te enseña la ruta resultante en AWS para que la confirmes.
|
|
384
408
|
3. Escribe el valor: texto plano o JSON en una línea.
|
|
385
409
|
4. Rellena las tags obligatorias (si `tags_activas = True`). `Environment` viene precargada con el entorno elegido. Con `obligatorias_vacias = True` puedes dejar alguna en blanco pulsando Enter: esas no se crearán en AWS.
|
|
386
410
|
5. Confirma en la pantalla de resumen. Si es un parámetro de RDS y falta su contraparte (común o privado), verás el aviso de correlación de naming ahí mismo.
|
|
@@ -4,7 +4,7 @@ ParamsX es una herramienta diseñada para gestionar y organizar parámetros de A
|
|
|
4
4
|
|
|
5
5
|
## ⚠ Breaking change en la versión 2.0.0
|
|
6
6
|
|
|
7
|
-
Si vienes de la 1.x tienes que **actualizar a mano tu `~/.xsoft/paramsx_config.py`**: `parameter_list` ya no es una lista de strings, ahora cada entrada es un diccionario
|
|
7
|
+
Si vienes de la 1.x tienes que **actualizar a mano tu `~/.xsoft/paramsx_config.py`**: `parameter_list` ya no es una lista de strings, ahora cada entrada es un diccionario que declara su perfil. La versión antigua **no es compatible** y ParamsX se niega a arrancar mostrando cómo migrarla. Detalle completo en el [CHANGELOG](CHANGELOG.md).
|
|
8
8
|
|
|
9
9
|
### Estructura Recomendada
|
|
10
10
|
La convención de naming es de 5 niveles, donde los últimos segmentos son opcionales según el caso:
|
|
@@ -77,10 +77,10 @@ Esto te permitirá mantener respaldos seguros o realizar migraciones/reorganizac
|
|
|
77
77
|
|
|
78
78
|
4. Crear nuevo parámetro
|
|
79
79
|
- Crea un parámetro desde cero sin salir de la herramienta. Te pedirá, en este orden:
|
|
80
|
-
- La ruta **sin el entorno**, igual que la declaras en `parameter_list`: el perfil
|
|
80
|
+
- La ruta **sin el entorno**, igual que la declaras en `parameter_list`: el perfil se encarga de colocarlo. Verás en pantalla la ruta resultante en AWS antes de seguir.
|
|
81
81
|
- El valor: texto plano o JSON en una línea (por ejemplo `{"host": "x", "user": "y", "pass": "z"}`), que se valida antes de continuar.
|
|
82
82
|
- Las tags obligatorias, si tienes `tags_activas = True`.
|
|
83
|
-
- El perfil que se usa es el que declares en `
|
|
83
|
+
- El perfil que se usa es el que declares en `perfil_nuevos`. Si tu perfil es de tipo `mixto`, escribe el `*` en la ruta para indicar dónde va el entorno.
|
|
84
84
|
- Antes de subirlo verás una pantalla de confirmación con la ruta, el valor y las tags. El parámetro se crea con `Overwrite=False`, así que nunca machaca uno existente.
|
|
85
85
|
- Tras crearlo aparecerá la próxima vez que leas la ruta correspondiente de tu `parameter_list`.
|
|
86
86
|
|
|
@@ -108,12 +108,56 @@ Este comando creará automáticamente una carpeta de configuración en tu direct
|
|
|
108
108
|
|
|
109
109
|
Dentro de esta carpeta, encontrarás el archivo paramsx_config.py. Este archivo contiene la configuración inicial que debes ajustar según tu entorno.
|
|
110
110
|
|
|
111
|
+
Si ya tenías configuración de una versión anterior, `paramsx configure` **no la sobrescribe**: te dice qué opciones nuevas no tienes y con qué valor por defecto se están rellenando, y si la configuración es válida. Con `paramsx configure --ejemplo` además deja la plantilla de esta versión en `paramsx_config.ejemplo.py`, al lado de la tuya, para que compares sin tocar nada.
|
|
112
|
+
|
|
111
113
|
Ejemplo del contenido de paramsx_config.py:
|
|
112
114
|
|
|
113
115
|
```python
|
|
114
116
|
## Configuraciones ParamsX
|
|
115
117
|
|
|
116
|
-
|
|
118
|
+
# --- Perfiles -------------------------------------------------------------
|
|
119
|
+
# Un perfil dice CÓMO se construye la ruta real en AWS a partir de la ruta que declaras
|
|
120
|
+
# en 'parameter_list' y del entorno que eliges en el menú. Los nombres son tuyos: define
|
|
121
|
+
# solo los que uses y llámalos como quieras. Un perfil tiene tres campos:
|
|
122
|
+
#
|
|
123
|
+
# campo | valores | qué decide
|
|
124
|
+
# ------------------+------------------------------------------+---------------------------
|
|
125
|
+
# posicion_entorno | inicio | final | mixto | ninguno | dónde va el entorno
|
|
126
|
+
# case_entorno | lower | upper | capitalize | cómo se escribe el entorno
|
|
127
|
+
# case_ruta | lower | upper | capitalize | ninguno | case de la ruta AL CREAR
|
|
128
|
+
#
|
|
129
|
+
# posicion_entorno -> dónde se coloca el entorno (ejemplos con el entorno 'dev'):
|
|
130
|
+
#
|
|
131
|
+
# valor | ruta declarada | ruta real en AWS
|
|
132
|
+
# ---------+-----------------+--------------------------------------------------------
|
|
133
|
+
# inicio | /rds | /dev/rds
|
|
134
|
+
# final | /API/STA | /API/STA/DEV
|
|
135
|
+
# mixto | /API/*/STA | /API/DEV/STA el '*' marca el sitio; uno y como segmento
|
|
136
|
+
# ninguno | /api/sta/auth | /api/sta/auth una cuenta AWS por entorno; case_entorno da igual
|
|
137
|
+
#
|
|
138
|
+
# case_entorno -> cómo se escribe ese entorno en la ruta:
|
|
139
|
+
#
|
|
140
|
+
# valor | 'dev' se escribe | ruta real de /API/STA con posicion_entorno=final
|
|
141
|
+
# ------------+------------------+------------------------------------------------
|
|
142
|
+
# lower | dev | /API/STA/dev
|
|
143
|
+
# upper | DEV | /API/STA/DEV
|
|
144
|
+
# capitalize | Dev | /API/STA/Dev
|
|
145
|
+
#
|
|
146
|
+
# case_ruta -> a qué case se fuerza la ruta que TÚ escribes al CREAR un parámetro
|
|
147
|
+
# (opción 4 del menú). No afecta a leer ni a editar: lo que ya existe en AWS se
|
|
148
|
+
# respeta siempre tal cual esté.
|
|
149
|
+
#
|
|
150
|
+
# valor | si escribes /API/MULTIAPI/Token, se crea
|
|
151
|
+
# ------------+-----------------------------------------
|
|
152
|
+
# lower | /api/multiapi/token
|
|
153
|
+
# upper | /API/MULTIAPI/TOKEN
|
|
154
|
+
# capitalize | /Api/Multiapi/Token
|
|
155
|
+
# ninguno | /API/MULTIAPI/Token
|
|
156
|
+
#
|
|
157
|
+
# Combina los tres campos como necesites: no hay una lista cerrada de perfiles. En el
|
|
158
|
+
# README tienes más ejemplos.
|
|
159
|
+
|
|
160
|
+
perfiles = {
|
|
117
161
|
"min": {"posicion_entorno": "inicio", "case_entorno": "lower", "case_ruta": "lower"},
|
|
118
162
|
"max": {"posicion_entorno": "final", "case_entorno": "upper", "case_ruta": "ninguno"},
|
|
119
163
|
"mixto_max": {"posicion_entorno": "mixto", "case_entorno": "upper", "case_ruta": "ninguno"},
|
|
@@ -126,101 +170,71 @@ configuraciones = {
|
|
|
126
170
|
"region_name": "eu-south-2", # Cambiar por tu región de AWS
|
|
127
171
|
"entornos": ['dev', 'pre', 'prod'], # SIEMPRE en minúscula, es la lista canónica única
|
|
128
172
|
"parameter_list": [
|
|
129
|
-
{"path": "/common", "
|
|
130
|
-
{"path": "/rds", "
|
|
131
|
-
{"path": "/EMAIL", "
|
|
132
|
-
{"path": "/API/STA", "
|
|
133
|
-
|
|
173
|
+
{"path": "/common", "perfil": "min"}, # -> /dev/common
|
|
174
|
+
{"path": "/rds", "perfil": "min"}, # -> /dev/rds
|
|
175
|
+
{"path": "/EMAIL", "perfil": "max"}, # -> /EMAIL/DEV
|
|
176
|
+
{"path": "/API/STA", "perfil": "max"}, # -> /API/STA/DEV
|
|
177
|
+
# Con 'mixto' acotas por debajo del entorno: esto lee solo stan_ai, en vez de
|
|
178
|
+
# todo lo que cuelga de /API/MULTIAPI/DEV
|
|
179
|
+
{"path": "/API/MULTIAPI/*/stan_ai", "perfil": "mixto_max"}, # -> /API/MULTIAPI/DEV/stan_ai
|
|
134
180
|
]
|
|
135
181
|
}
|
|
136
182
|
|
|
137
|
-
|
|
183
|
+
# Perfil que se usa al crear un parámetro nuevo (opción 4 del menú).
|
|
184
|
+
# Si no lo defines, se usa el primero de 'perfiles'.
|
|
185
|
+
perfil_nuevos = "min"
|
|
138
186
|
|
|
187
|
+
# ¿El nombre del fichero exportado incluye la ruta leída?
|
|
188
|
+
# False -> parameters_dev.py (comportamiento de siempre)
|
|
189
|
+
# True -> parameters_dev__API_STA__max.py (uno por entrada y entorno: lleva el
|
|
190
|
+
# entorno, la ruta y el perfil, porque dos entradas pueden compartir ruta)
|
|
191
|
+
# Ponlo en True si sueles leer varias rutas del mismo entorno y no quieres que la
|
|
192
|
+
# segunda lectura te machaque el fichero de la primera.
|
|
139
193
|
fichero_por_ruta = False
|
|
140
194
|
|
|
141
195
|
|
|
142
196
|
## Configuraciones Tags
|
|
143
197
|
|
|
198
|
+
# Gestionar las tags de los parámetros: leerlas de AWS, exponerlas en el fichero
|
|
199
|
+
# exportado para editarlas y validar las obligatorias al cargar.
|
|
200
|
+
# True -> las tags viajan en el fichero y se validan.
|
|
201
|
+
# False -> no aparecen tags en el fichero y no se valida nada.
|
|
202
|
+
# En cuentas cuyo control de acceso va por tags (ABAC vía IAM) esto debe estar en True.
|
|
144
203
|
tags_activas = True
|
|
145
204
|
|
|
205
|
+
# Solo aplica si tags_activas = True.
|
|
206
|
+
# False -> validación bloqueante: si a un parámetro le falta alguna tag obligatoria
|
|
207
|
+
# no se sube (ni su valor ni sus tags).
|
|
208
|
+
# True -> se permiten vacías: el parámetro se sube igualmente y las tags sin valor
|
|
209
|
+
# simplemente NO se crean en AWS (no se suben como etiquetas vacías).
|
|
146
210
|
obligatorias_vacias = False
|
|
147
211
|
|
|
212
|
+
# Tags que se exigen en cada parámetro cuando tags_activas = True. La lista es libre:
|
|
213
|
+
# estas 8 son las que sostienen el control de acceso ABAC vía IAM de nuestra cuenta.
|
|
148
214
|
tags_obligatorias = [
|
|
149
|
-
"Application",
|
|
150
|
-
"
|
|
215
|
+
"Application",
|
|
216
|
+
"Environment",
|
|
217
|
+
"Owner",
|
|
218
|
+
"Project",
|
|
219
|
+
"Product",
|
|
220
|
+
"Service",
|
|
221
|
+
"Component",
|
|
222
|
+
"ManagedBy",
|
|
151
223
|
]
|
|
152
224
|
```
|
|
153
225
|
Nota: Si el archivo paramsx_config.py ya existe, no será sobrescrito durante la instalación para proteger las configuraciones personalizadas.
|
|
154
226
|
|
|
155
|
-
### Los perfiles
|
|
156
|
-
|
|
157
|
-
Cada organización nombra sus parámetros a su manera, así que ParamsX no impone ninguna convención: **tú defines los perfiles que uses en el diccionario `naming` y les pones el nombre que quieras**. Cada entrada de `parameter_list` declara con qué perfil se construye su ruta completa.
|
|
158
|
-
|
|
159
|
-
Un perfil tiene tres campos:
|
|
160
|
-
|
|
161
|
-
| Campo | Valores | Qué decide |
|
|
162
|
-
|---|---|---|
|
|
163
|
-
| `posicion_entorno` | `inicio` \| `final` \| `mixto` \| `ninguno` | Dónde va el entorno dentro de la ruta. |
|
|
164
|
-
| `case_entorno` | `lower` \| `upper` \| `capitalize` | Cómo se escribe el entorno. |
|
|
165
|
-
| `case_ruta` | `lower` \| `upper` \| `capitalize` \| `ninguno` | Case de la ruta al crear parámetros. |
|
|
166
|
-
|
|
167
|
-
Y en detalle:
|
|
168
|
-
|
|
169
|
-
**`posicion_entorno`** — dónde se coloca el entorno, con el entorno `dev`:
|
|
227
|
+
### Los perfiles
|
|
170
228
|
|
|
171
|
-
|
|
172
|
-
|---|---|---|---|
|
|
173
|
-
| `inicio` | `/rds` | `/dev/rds` | |
|
|
174
|
-
| `final` | `/API/STA` | `/API/STA/DEV` | |
|
|
175
|
-
| `mixto` | `/API/*/STA` | `/API/DEV/STA` | el `*` marca el sitio |
|
|
176
|
-
| `ninguno` | `/api/sta/auth` | `/api/sta/auth` | una cuenta AWS por entorno |
|
|
177
|
-
|
|
178
|
-
**`case_entorno`** — cómo se escribe ese entorno en la ruta:
|
|
179
|
-
|
|
180
|
-
| Valor | `dev` se escribe | `/API/STA` con `posicion_entorno: final` |
|
|
181
|
-
|---|---|---|
|
|
182
|
-
| `lower` | `dev` | `/API/STA/dev` |
|
|
183
|
-
| `upper` | `DEV` | `/API/STA/DEV` |
|
|
184
|
-
| `capitalize` | `Dev` | `/API/STA/Dev` |
|
|
185
|
-
|
|
186
|
-
**`case_ruta`** — a qué case se fuerza la ruta que escribes al **crear** un parámetro (opción 4). No afecta a leer ni a editar: lo que ya existe en AWS se respeta siempre tal cual esté.
|
|
187
|
-
|
|
188
|
-
| Valor | Si escribes `/API/MULTIAPI/Token`, se crea |
|
|
189
|
-
|---|---|
|
|
190
|
-
| `lower` | `/api/multiapi/token` |
|
|
191
|
-
| `upper` | `/API/MULTIAPI/TOKEN` |
|
|
192
|
-
| `capitalize` | `/Api/Multiapi/Token` |
|
|
193
|
-
| `ninguno` | `/API/MULTIAPI/Token` |
|
|
229
|
+
Cada organización nombra sus parámetros a su manera, así que ParamsX no impone ninguna convención: **tú defines los perfiles que uses en el diccionario `perfiles` y les pones el nombre que quieras**. Cada entrada de `parameter_list` declara con qué perfil se construye su ruta completa, con la clave `perfil`. Los tres campos de un perfil y sus valores están explicados en el propio fichero de configuración, ahí arriba.
|
|
194
230
|
|
|
195
231
|
**No hay una lista cerrada de perfiles.** Los tres campos se combinan libremente, así que la plantilla no intenta traértelos todos: define los dos o tres que use tu organización y olvídate del resto. `min` y `max` vienen predefinidos porque son los que ParamsX traía antes de que los perfiles fueran configurables.
|
|
196
232
|
|
|
197
|
-
|
|
233
|
+
**Para qué sirve el `*`.** Además de colocar el entorno donde quieras, acota la lectura a un solo subárbol: con `/API/MULTIAPI/*/stan_ai` lees únicamente `/API/MULTIAPI/DEV/stan_ai`, en vez de todo lo que cuelga de `/API/MULTIAPI/DEV`. Debe ser un segmento entero, aparecer **exactamente una vez** y solo se admite en perfiles `mixto`: si el perfil y la ruta no cuentan la misma historia, ParamsX te lo dice al arrancar en vez de leer una ruta inexistente y devolverte una lista vacía.
|
|
198
234
|
|
|
199
|
-
|
|
235
|
+
**Los entornos.** Ya no existe la lista `entornos_old`: el entorno sale siempre de la lista canónica `entornos` (en minúscula), aplicándole el `case_entorno` del perfil. Si en tus rutas se llama `staging` en vez de `pre`, ponlo así en `entornos`.
|
|
200
236
|
|
|
201
|
-
|
|
202
|
-
|
|
203
|
-
Ejemplo completo de una `parameter_list` real, mezclando perfiles:
|
|
204
|
-
|
|
205
|
-
```python
|
|
206
|
-
"parameter_list": [
|
|
207
|
-
{"path": "/common", "convencion": "min"},
|
|
208
|
-
{"path": "/rds", "convencion": "min"},
|
|
209
|
-
{"path": "/api", "convencion": "min"},
|
|
210
|
-
{"path": "/INFRA", "convencion": "max"},
|
|
211
|
-
{"path": "/API/STA", "convencion": "max"},
|
|
212
|
-
{"path": "/API/p15", "convencion": "max"},
|
|
213
|
-
{"path": "/API/MULTIAPI", "convencion": "max"},
|
|
214
|
-
{"path": "/APP/Alertas", "convencion": "max"},
|
|
215
|
-
{"path": "/BUCKETS", "convencion": "max"},
|
|
216
|
-
{"path": "/EMAIL", "convencion": "max"},
|
|
217
|
-
{"path": "/INFERENCIAS/TASA_DMI", "convencion": "max"},
|
|
218
|
-
{"path": "/CEE/CEXGEN", "convencion": "max"},
|
|
219
|
-
{"path": "/API/MULTIAPI/*/stan_ai", "convencion": "mixto_max"},
|
|
220
|
-
]
|
|
221
|
-
```
|
|
222
|
-
|
|
223
|
-
Sobre mayúsculas y minúsculas: ParamsX **no renombra ni fuerza el case de los parámetros que ya existen**, los lee y edita tal cual estén. El `case_ruta` del perfil solo entra en juego al crear parámetros nuevos.
|
|
237
|
+
Y ParamsX **no renombra ni fuerza el case de los parámetros que ya existen**: los lee y edita tal cual estén. El `case_ruta` del perfil solo entra en juego al crear parámetros nuevos.
|
|
224
238
|
|
|
225
239
|
### Un fichero por ruta: `fichero_por_ruta`
|
|
226
240
|
|
|
@@ -232,15 +246,15 @@ En el nombre van el entorno, la ruta y el perfil, porque dos entradas pueden com
|
|
|
232
246
|
|
|
233
247
|
| Entrada | Fichero |
|
|
234
248
|
|---|---|
|
|
235
|
-
| `{"path": "/API/STA", "
|
|
236
|
-
| `{"path": "/API/*/STA", "
|
|
249
|
+
| `{"path": "/API/STA", "perfil": "max"}` | `parameters_dev__API_STA__max.py` |
|
|
250
|
+
| `{"path": "/API/*/STA", "perfil": "mixto_max"}` | `parameters_dev__API_env_STA__mixto_max.py` |
|
|
237
251
|
|
|
238
252
|
### Cómo acotar tu parameter_list (recomendación)
|
|
239
253
|
|
|
240
254
|
`parameter_list` es solo tu vista de trabajo: **la seguridad real la impone IAM, no este fichero**. La recomendación de uso es:
|
|
241
255
|
|
|
242
|
-
- **Admins**: pueden configurar rutas raíz amplias, por ejemplo `{"path": "/rds", "
|
|
243
|
-
- **Usuarios normales**: conviene acotar la ruta a lo que su rol IAM tiene realmente autorizado, por ejemplo `{"path": "/rds/cee-dev/api", "
|
|
256
|
+
- **Admins**: pueden configurar rutas raíz amplias, por ejemplo `{"path": "/rds", "perfil": "min"}` → `/dev/rds`.
|
|
257
|
+
- **Usuarios normales**: conviene acotar la ruta a lo que su rol IAM tiene realmente autorizado, por ejemplo `{"path": "/rds/cee-dev/api", "perfil": "min"}` → `/dev/rds/cee-dev/api`.
|
|
244
258
|
|
|
245
259
|
Si configuras una ruta más amplia que tus permisos, no pasa nada grave: ParamsX te avisará con un mensaje claro de acceso denegado en vez de una traza de boto3. Pero afinar la ruta te ahorra el error.
|
|
246
260
|
|
|
@@ -322,7 +336,17 @@ En algunos sistemas (especialmente en entornos corporativos como Windows), el PA
|
|
|
322
336
|
```source ~/.zshrc # Para zsh```
|
|
323
337
|
|
|
324
338
|
Una vez instalado, verifica que el comando paramsx esté disponible ejecutando:
|
|
325
|
-
```paramsx --
|
|
339
|
+
```paramsx --version```
|
|
340
|
+
|
|
341
|
+
Comandos disponibles:
|
|
342
|
+
|
|
343
|
+
| Comando | Qué hace |
|
|
344
|
+
|---|---|
|
|
345
|
+
| `paramsx` | Abre el menú interactivo (necesita configuración). |
|
|
346
|
+
| `paramsx configure` | Crea la configuración la primera vez; si ya existe, la revisa sin tocarla. |
|
|
347
|
+
| `paramsx configure --ejemplo` | Además deja la plantilla de esta versión al lado, para comparar. |
|
|
348
|
+
| `paramsx --version` | Versión instalada. |
|
|
349
|
+
| `paramsx --help` | Ayuda, con el resumen de todas las opciones de configuración. |
|
|
326
350
|
|
|
327
351
|
|
|
328
352
|
## Modo de empleo
|
|
@@ -339,7 +363,7 @@ El programa mostrará un menú donde Podrás:
|
|
|
339
363
|
- Crear un parámetro nuevo.
|
|
340
364
|
|
|
341
365
|
### Leer Parámetros:
|
|
342
|
-
1. Selecciona la opción "Leer parámetros" en el menú. La lista muestra cada ruta con su perfil
|
|
366
|
+
1. Selecciona la opción "Leer parámetros" en el menú. La lista muestra cada ruta con su perfil, por ejemplo `/rds [min]` o `/API/STA [max]`.
|
|
343
367
|
2. Elige el prefijo y el entorno que deseas consultar.
|
|
344
368
|
3. Los parámetros serán descargados y guardados en archivos como:
|
|
345
369
|
- parameters_dev.py
|
|
@@ -360,7 +384,7 @@ El programa mostrará un menú donde Podrás:
|
|
|
360
384
|
|
|
361
385
|
### Crear un parámetro nuevo:
|
|
362
386
|
1. Selecciona la opción "Crear nuevo parámetro" y elige el entorno.
|
|
363
|
-
2. Escribe la ruta **sin el entorno**, como en tu `parameter_list`: ParamsX le aplica el perfil de `
|
|
387
|
+
2. Escribe la ruta **sin el entorno**, como en tu `parameter_list`: ParamsX le aplica el perfil de `perfil_nuevos` y te enseña la ruta resultante en AWS para que la confirmes.
|
|
364
388
|
3. Escribe el valor: texto plano o JSON en una línea.
|
|
365
389
|
4. Rellena las tags obligatorias (si `tags_activas = True`). `Environment` viene precargada con el entorno elegido. Con `obligatorias_vacias = True` puedes dejar alguna en blanco pulsando Enter: esas no se crearán en AWS.
|
|
366
390
|
5. Confirma en la pantalla de resumen. Si es un parámetro de RDS y falta su contraparte (común o privado), verás el aviso de correlación de naming ahí mismo.
|
|
@@ -0,0 +1 @@
|
|
|
1
|
+
__version__ = "2.2.2"
|