No tengo la intención de hacer más trabajo en Babushka (de hecho, no lo he hecho en algún tiempo).
Tuve la idea y comencé a trabajar en el proyecto en 2009. En ese momento, Docker e incluso Vagrant aún no se había concebido. En la parte, quería construir una alternativa más simple y a pequeña escala a los gustos de Chef and Puppet, y en parte comenzó como un experimento en qué tan lejos podía perfeccionar un DSL de Ruby y en qué medida podría apoyarme en él. hacer un trabajo útil. Tenía una pelota trabajando en ello y aprendí mucho, y estoy orgulloso del hecho de que el diseño inicial demostró ser el sonido. Estoy menos orgulloso de ciertas partes de la implementación: Hoowee escribiría algunos bits de ese código de manera diferente hoy, pero todos éramos jóvenes una vez.
En estos días las cosas son muy diferentes. Con los contenedores modernos y la inmutabilidad que proporcionan, junto con herramientas como Terraform, Kubernetes, etc., Babushka y su enfoque basado en mutaciones están bastante anticuados. De hecho, requerir un buen babushka para un trabajo de infraestructura grave hoy podría considerarse una especie de señal de advertencia.
En cuanto a la configuración de una nueva computadora portátil, etc., he aprendido la larga forma en que un script de shell tonto que copia algunas preferencias en su lugar, ejecuta algunos comandos defaults write
, etc., junto con algunos pasos manuales, es mucho más fácil de mantener. Cuanto más llegue un proceso automatizado en macOS, más rápido se reducirá de compatibilidad, y en cualquier caso, configurar una nueva máquina es una ocurrencia lo suficientemente rara para mí que no valga la pena apuntar a una automatización perfecta.
Gracias a todos los que han contribuido y lo utilizaron a lo largo de los años. Como siempre, si desea utilizarlo de alguna manera, elija su vida, simplemente no tengo la intención de hacer más cambios en este repositorio principal. Bueno, tal vez un día lluvioso refactoraré los trozos peludos, ya veremos.
Saludos y todo lo mejor.
Babushka es una herramienta de línea de comandos para automatizar las tareas informáticas. Cada parte distinta del trabajo se expresa como una dependencia (DEP), que comprende una prueba y el código para hacer que esa prueba pase.
dep 'on git branch' , :branch do
met? {
current_branch = shell ( 'git branch' ) . split ( " n " ) . collapse ( /^ * / ) . first
log "Currently on #{ current_branch } ."
current_branch == branch
}
meet {
log_shell ( "Checking out #{ branch } " , 'git' , 'checkout' , branch )
}
end
Arriba hay un DEP expositivo que puede lograr el objetivo modesto de estar en la rama GIT correcta (tenga en cuenta el parámetro denotado por el símbolo de: rama). ¿Está construido con las dos palabras DSL met?
y meet
, que contiene la lógica de cada dep, separando la prueba (¿se cumple la dependencia?) del código (cumplir con la dependencia).
Ejecutar este DEP cuando se requiere un cambio de rama muestra cómo Babushka hace su trabajo en bloques de Met/Meet/Met: una prueba fallida, una acción tomada ciegamente y luego la misma prueba nuevamente, pasando ahora como resultado.
$ bin/babushka.rb 'on git branch' branch=stable
on git branch {
Currently on master.
meet {
Checking out stable... done.
}
Currently on stable.
} ✓ on git branch
Sin embargo, si ya estamos en la rama correcta, la prueba inicial ya está pasando, por lo que no hay trabajo por hacer.
$ bin/babushka.rb 'on git branch' branch=stable
on git branch {
Currently on stable.
} ✓ on git branch
Eso está muy bien para una tarea aislada. Para lograr algo más grande, las tareas tienen que activar otras, que es donde requires
la tercera palabra DSL.
dep 'on git branch' , :branch do
requires 'git'
# ...
Antes de que Babushka procese un DEP en la moda Met/Meet/Met descrita anteriormente, todos sus requisitos se procesan para su finalización de la misma manera. Eso refleja la realidad: preguntar si estamos en la rama Git correcta ni siquiera tiene sentido si Git no está instalado.
$ bin/babushka.rb 'on git branch' branch=stable
on git branch {
git {
'git' runs from /usr/bin.
✓ git is 2.3.8, which is >= 1.6.
} ✓ git
Currently on stable.
} ✓ on git branch
La palabra DSL complementaria requires_when_unmet
se puede usar para especificar las dependencias requeridas solo cuando se encuentra que un DEP dado no está satisfecho, y eso se puede omitir cuando el DEP ya se cumple. (Las herramientas de compilación son un buen ejemplo de tal requisito).
Hay otras cosas sobre las que aprender, como las plantillas DEP, las fuentes DEP y las pocas palabras restantes en el DSL de Babushka, pero lo anterior es la nuez. Si encadena unas pocas docenas de Deps como este juntos, puede aprovisionar un servidor desde cero o hacer cualquier otra cosa que desee.
Hay una documentación mucho más detallada en el sitio web, junto con la documentación por método que se puede ver aquí.
Babushka se instala más fácilmente usando babushka.me/up
, un script de shell que instala Babushka a través de Git (y sus dependencias, Ruby y Git, a través del administrador de paquetes de su sistema si es necesario). Es seguro ejecutar en los sistemas existentes y está destinado a ser utilizado como el primer comando de shell en un nuevo sistema también. Puede instalar Babushka de esta manera con curl
o wget
:
sh -c "`curl https://babushka.me/up`"
Si prefiere instalar manualmente, todo lo que necesita hacer es clonar el repositorio GIT (o extraer un archivo de él) y si lo desea, vincule bin/babushka.rb
en su camino como 'babushka'.
Consulte la documentación de instalación para obtener detalles sobre la personalización de la instalación, incluido el bloqueo de versiones específicas e instalación desde horquillas utilizando babushka.me/up
.
Babushka mismo debería correr en cualquier UNIX; No hay nada en el núcleo de Babushka que requiera algo más que Unix, Ruby y Git.
Desarrollo Babushka en MacOS y lo uso principalmente en Ubuntu, por lo que Homebrew y Apt son los gerentes de paquetes mejor apoyados. También hay un apoyo YUM (Redhat/Fedora/Centos) y Pacman (Arch), gracias a las contribuciones de otros. En otros sistemas, las operaciones específicas (como instalar un paquete utilizando el Administrador de paquetes de ese sistema) fallarán con un mensaje de error, pero por lo demás Babushka debería funcionar bien. En cualquier caso, los parches son más bienvenidos.
Babushka aprovecha estas bibliotecas Ruby:
Muchas gracias a todos los que han contribuido a Babushka, ya sea enviando parches, discutiendo ideas de diseño conmigo, probando o simplemente dando sus comentarios.
Una lista de contribuyentes aquí inevitablemente se desactualiza: la página de contribuyentes contiene la lista completa. Además, la versión de versión siempre detalla lo que cambió y quién ayudó en sus mensajes de confirmación.
Babushka tiene licencia bajo la licencia BSD de tres cláusulas, a excepción de lib/levenshtein/levenshtein.rb
, que tiene licencia bajo la licencia MIT.
La licencia BSD se puede encontrar en su totalidad en el archivo de licencia, y la licencia MIT se puede encontrar en la parte superior de lib/levenshtein/levenshtein.rb
.