Elige tu punto de partida
Ejecuta el arranque de Basement solo en el host que quieras configurar. Para
echar un primer vistazo a la CLI sin instalar servicios, elige la vía de la
cadena de herramientas. Los usuarios de Windows pueden obtener la CLI del ZIP de
la versión pública; eso no convierte a Windows en un destino de ejecución nativo
compatible con Basement. Consulta la
referencia de compatibilidad de sistemas operativos
para el destino de instalación.
1. Comprueba la CLI y crea un workspace
Tras instalar la cadena de herramientas, abre una terminal:2. Guarda tus elecciones
Para un Basement Kit con los valores por defecto de su catálogo:init crea stack-spec.yaml y la custodia local del propietario. Imprime la
ruta de la configuración guardada y los siguientes comandos validate y
generate. No ha instalado servicios.
Los valores por defecto del catálogo se registran como elecciones explícitas. Se
solicita la información necesaria cuando el kit seleccionado la requiere. Para
incluir el workload de fotos del kit en un workspace nuevo, usa
esto en lugar del comando init anterior:
--non-interactive a init. Entonces, la falta de una
entrada obligatoria produce un error en lugar de preguntar. Este indicador no
aprueba acciones de despliegue posteriores. stackkit init --help documenta las
opciones disponibles; los indicadores marcados como compatibilidad heredada
quedan fuera de este recorrido nativo.
3. Valida, genera y revisa
readiness.generation.status y readiness.apply.status y lee los
posibles bloqueos. Corrige la configuración y vuelve a generar si es necesario.
Un plan listo no significa que las aplicaciones ya estén en funcionamiento.
4. Comprueba el destino y aplica
En el host de destino compatible, con el mismo workspace:prepare comprueba los requisitos previos del host,
como Docker, Compose, el almacenamiento y los puertos. No instala los paquetes
del host que falten. Resuelve los requisitos previos que se indiquen antes de
aplicar.
apply modifica el host. Revisa su solicitud de aprobación y los cambios
previstos. Sigue Revisar, aplicar y verificar
para las comprobaciones detalladas del ciclo de vida. Si usaste el arranque de
Basement, la aplicación inicial ya se ha realizado; no la repitas solo para
terminar un recorrido.
5. Averigua qué se puede usar
verify comprueba el stack spec, el estado del despliegue, el daemon de Docker,
los contenedores de StackKit y su estado de salud y, con --http, las rutas del
resumen de acceso generado. Cada comprobación fallida indica su motivo. Una
dirección configurada por sí sola no demuestra que una aplicación sea
accesible; una comprobación HTTP correcta sí.
Sigue la guía de configuración de la aplicación cuando aún haya que configurar
una cuenta. Usa stackkit setup --help para las acciones de configuración
compatibles. Termina abriendo la aplicación y realizando una pequeña tarea real,
como añadir una foto de prueba a tu biblioteca de fotos. Que la instalación de
la CLI haya tenido éxito no demuestra por sí solo que esta tarea funcione.
6. Retoma y resuelve problemas
Vuelve al mismo directorio de despliegue:drift detect compara el runtime de Compose en vivo con el plan resuelto, los
artefactos generados y la evidencia firmada de la aplicación sin cambiar nada, y
logs get lee el registro estructurado de una ejecución de logs list. Usa el
motivo y la siguiente acción indicados para continuar. Conserva el workspace cuando falle una operación; no empieces de nuevo con init ni edites
los archivos generados para saltarte un bloqueo. Mantén privadas las claves del
propietario y los registros de acceso, y revisa la salida de diagnóstico antes
de compartirla.
Para el mantenimiento continuo, usa las
operaciones del día 2 y
Copia de seguridad y restauración. La
selección de kits y la experiencia de configuración guiada en Techstack son una
continuación opcional; no son necesarias para este flujo local de la CLI.