Dockerització del Mailtoticket #196
Conversation
|
@jguillem crec que aquest PR no està basat en la branca master actual, oi? Diria que inclou canvis que estan en algun altre PR i que per tant no correspon posar-los aquí. |
Correcte. He fet els canvis sobre la branca feature_api_rest_identitat com està a la descripció del request. Si es possible fer un pull request sobre d'una altre branca (i si m'ho permets, perquè igual es lia massa) miro com fer-ho. Del contrari podem ignorar aquest pull request i ja ho tornaria a fer un cop feu el merge de la branca feature_api_rest_identitat al master. Com em diguis. |
There was a problem hiding this comment.
La idea de tenir el mailtoticket i el fetchmail junts és temptadora i per tant és quelcom a considerar, però hi ha altres aspectes d'aquesta proposta que crec que s'haurien de revisar, el més important dels quals és deslligar la creació de la imatge docker d'una branca determinada.
| @@ -0,0 +1,20 @@ | |||
| FROM python:2.7 | |||
| RUN git clone --single-branch --branch feature_api_rest_identitat https://github.com/UPC/mailtoticket.git | |||
There was a problem hiding this comment.
Crec que és mala idea clonar el repositori durant la construcció de la imatge, sobretot si el motiu és generar la imatge amb el codi d'una branca concreta.
There was a problem hiding this comment.
La meva idea era generar una imatge out-of-the-box (mínim de passos), de cara a fer les proves m'anava bé.
Per adaptar el dockerfile en un context de branca master amb fetchmail inclòs, es pot canviar el git clone per un COPY de tot.
Llavors el procés seria:
1- Git clone
2- Modificar els settings de mailtoticket i fetchmail
3- Fer el build
| folder "mailtoticket" | ||
| mda "/bin/sh -c 'cat | /usr/local/bin/python /mailtoticket/mailtoticket.py'" | ||
| ssl | ||
| nokeep |
There was a problem hiding this comment.
Jo anomenaria l'exemple de configuració del fetchmail d'una altra manera que:
- no comenci amb un punt perquè el fitxer no quedi ocult
- el nom digui clarament que és un exemple, e.g.
fetchmailrc.example
| username "suport.unitat" | ||
| password "contrasenya" | ||
| folder "mailtoticket" | ||
| mda "/bin/sh -c 'cat | /usr/local/bin/python /mailtoticket/mailtoticket.py'" |
There was a problem hiding this comment.
Per què caldria posar /bin/sh -c 'cat | ...' enlloc de cridar el python directament amb el mailtoticket com a argument, tal com indica la documentació del wiki?
There was a problem hiding this comment.
Per alguna raó no em funcionava amb la info de la wiki i esbrinant exemples de configuració de fetchmail, aquesta opció em va funcionar. Puc tornar a provar per si va ser una falsa impressió.
| @@ -0,0 +1,9 @@ | |||
| set logfile "/tmp/fetchmail.log" | |||
There was a problem hiding this comment.
En un contenidor de docker els logs han d'anar a stdout i stderr perquè el sistema de fitxers és efímer. Per tant crec que aquesta línia no hi hauria de ser.
There was a problem hiding this comment.
No tinc controlat el tema del logging en contenidors. Si treient l'entrada "set logfile" ja s'envien els errors per stdout, doncs es fàcil de solucionar.
| RUN apt-get update | ||
| RUN apt-get upgrade -y | ||
| RUN apt-get install -y fetchmail | ||
| RUN apt-get install -y cron |
There was a problem hiding this comment.
Podem debatre si el fetchmail hauria d'estar dins el mateix contenidor que el mailtoticket (jo penso que haurien d'estar en contenidors separats) però el que segur que no té sentit és tenir un contenidor amb un cron només per executar el fetchmail.
Si el contenidor s'executa a un servidor, aquest ja tindrà un cron des del que es pot executar el contenidor amb docker run. Si el contenidor està a mycontainers, allà ja hi ha serveis de tipus cron que poden executar contenidors periòdicament. A més a més, el fetchmail té un mode dimoni que també podria ser interessant de valorar.
Com més senzill sigui el contenidor més fàcil serà de mantenir, debuggar, operar i escalar, per tant crec que el cron sobra.
There was a problem hiding this comment.
No et sabria dir quina configuració implicaria tenir el fetchmail i el mailtoticket en dockers separats per que la cosa funcioni. Jo apostaria per tenir els dos en el mateix docker, sigui tirant del dimoni de fetchmail o bé pensant en el temporitzador que teniu muntat en mycontainers. Tinc pendent demanar l'accés a aquest servei per a fer proves.
| @@ -0,0 +1,20 @@ | |||
| FROM python:2.7 | |||
There was a problem hiding this comment.
En general s'acostuma a anomenar el fixer Dockerfile amb la D majúscula. Crec que seria bona idea canviar-li el nom, sobretot si volem que la gent del docker hub el trobin per fer imatges automàtiques.
Sí que es pot però només té sentit si els canvis formen part del mateix objectiu. En aquest cas, crec que fer el PR sobre la branca feature_api_rest_identitat no seria correcte perquè barrejaria canvis amb objectius diferents.
No crec que calgui esperar a fer les correccions. Us he fet alguns comentaris que m'agradaria que valoreu i comentem abans de decidir per quina proposta ens decantem per la imatge oficial de docker. |
Afegeix el dockerfile el entrypoint.sh i un exemple del fitxer de configuració de fetchmail fetchmailrc.
Els canvis han estats fets a sobre de la branca feature_api_rest_identitat. Es a dir la branca amb codi adaptat a la nova APP REST d'identitat.