search

ernestoalejo / virtual-vulcano

http://ernestoalejo.github.io/virtual-vulcano
BSD 2-Clause "Simplified" License
5 stars 2 forks source link

usar mocha para test #8

Closed JJ closed 9 years ago

JJ commented 9 years ago

Y añadirlo.

ernestoalejo commented 9 years ago

Hemos terminado usando Jasmine para poder usar BDD: https://github.com/ernestoalejo/virtual-vulcano/blob/master/web/lib/start.spec.js

JJ commented 9 years ago

El enlace no funciona, pero me parece bien lo que queráis usar. De hecho, mocha lo puedes configurar también para BDD, si es lo que queréis.

ernestoalejo commented 9 years ago

Oops... es que acabamos de mover a una subcarpeta todos los ficheros de la aplicación. Link actualizado: https://github.com/ernestoalejo/virtual-vulcano/blob/master/web/app/lib/start.spec.js

JJ commented 9 years ago

Deberíais usar alguna herramienta tipo Ansible o Rex para hacer las copias y despliegues. scp no es un modo adecuado de hacerlo: no conserva los timestamps, por ejemplo.

JJ commented 9 years ago

Madre mía, promesas. ¿Vosotros sabéis donde os estáis metiendo?

ernestoalejo commented 9 years ago

@JJ Con lo de las promesas si.

Lo de Ansible es que realmente parecía overkill para la herramienta. Le cuento los pasos por si podemos mejorarlo:

  1. El usuario nos da un servicio a través de la página online (un fichero de CoreOS de ~20 líneas con la descripción del trabajo que quiere lanzar en sus máquinas)
  2. Generamos un pequeño fichero bash temporal que ejecute con fleetctl el servicio.
  3. Usamos scp para copiar el script y ssh para lanzarlo.
  4. fleetctl y docker se encargan ellos solos de descargar e instalar automáticamente lo necesario para ejecutar el trabajo.

Realmente el tema es que en la máquina a la que estamos mandando no hay nada instalado más que docker y lo que lleve linux (ni siquiera python, porque es un CoreOS). No podemos depender de nada más para lanzarle el servicio en sus servidores al cliente de nuestra app.

Para nosotros internamente si estamos en vías de montar Travis para integración continua.

JJ commented 9 years ago

El 14 de diciembre de 2014, 17:30, Ernesto Alejo notifications@github.com escribió:

@JJ https://github.com/JJ Con lo de las promesas si.

Lo de Ansible es que realmente parecía overkill para la herramienta. Le cuento los pasos por si podemos mejorarlo:

  1. El usuario nos da un servicio a través de la página online (un fichero de CoreOS de ~20 líneas con la descripción del trabajo que quiere lanzar en sus máquinas)
  2. Generamos un pequeño fichero bash temporal que ejecute con fleetctl el servicio.

El cliente puede no tener bash, o usar alguna cosa especial. Ansible, chef o rex se encargan de crear scripts independientes del sistema operativo.

  1. Usamos scp para copiar el script y ssh para lanzarlo.

En el cliente debéis usar siempre control de versiones. Si vais a copiar algo, que lo haga el cliente con git. Así es más fácil sincronizar y sabéis en qué commit está cada código cliente.

  1. fleetctl y docker se encargan ellos solos de descargar e instalar automáticamente lo necesario para ejecutar el trabajo.

Realmente el tema es que en la máquina a la que estamos mandando no hay nada instalado más que docker y lo que lleve linux (ni siquiera python, porque es un CoreOS). No podemos depender de nada más para lanzarle el servicio en sus servidores al cliente de nuestra app.

Hay muchos Linux. No sé si podréis usar Ansible o no, pero no debéis usar scp para copiar cosas. En cuanto que la cosa se complique lo más mínimo, generar un bash (que es lo que hace Ansible, sólo que adaptado a la

máquina) no va a dar de sí.

JJ

ernestoalejo commented 9 years ago

Tenemos a nuestro favor la simplicidad de que solo accedemos a CoreOS, no controlamos diversos sistemas operativos en las máquinas (por lo menos de momento...)

De Ansible es que había leido esto:

On the managed nodes, you only need Python 2.4 or late

en http://docs.ansible.com/intro_installation.html. Por eso comentaba que CoreOS no lleva ni siquiera python instalado. Por lo que dicen en la documentación puedes usar raw, que de todas maneras tiene las mismas desventajas que comenta porque no dejan de ser comandos de shell. O alternativamente, bajarnos algo como pypy dentro de la máquina:

https://github.com/defunctzombie/ansible-coreos-bootstrap/blob/master/files/bootstrap.sh

y una vez instalado generar el script de Ansible para instalar lo que de verdad queríamos.

Pero queríamos evitarlo porque serían muchas presuposiciones sobre espacio, capacidad de acceso directa a la red, etc. que estaríamos haciendo sobre servidores en los no tenemos control alguno porque son del cliente. Eso y la complejidad de tener que instalar Ansible además del servicio que nos pide el cliente.

JJ commented 9 years ago

Como tú veas. Pero, aparte de la conveniencia o no, es parte del temario de la asignatura, así que si vais haciéndolo ahora es algo que os ahorraréis más adelante.