Reprise du message précédent :
le contenu de la RAM pourrait être persisté sur le filesystem

d'ailleurs la méthode pause sur un container docker est un peu débile parce que le container n'est plus accessible mais la RAM et le CPU fluctuent toujours donc le container est toujours en activité

je ne comprends pas l'intérêt de cette méthode

Si c'est possible    
Tu peux faire ce que tu demandes avec le idling de Openshift. Mais il faut passer sur Kubernetes    
 
https://docs.openshift.com/containe [...] tions.html
 
Sinon, on a des dev qui ont developper un proxy pour ça sur une autre techno.
Le principe tous les containers sont détruits / existent pas, quand tu fais un appel http ça démarre, pendant ce temps tu as un message pour te dire d'attendre, et une fois le service up tu es redirigé sur la page. ça sert pour les environnements de développement et ainsi économiser des ressources cloud. (en pratique tu attends moins de 1 sec, et tu économises 70% de facture).

P'tain rapide a démarrer le container  

Bah c'est du burst
T'as vu la vitesse à laquelle aws peut boiter des VM

Nope je fais tourner mes cluster openshift sur du hyperv on prem et en plus de tout ça j'ai pratiquement que des pods avec des jvm donc on est pas vraiment dans l'instantanéité.
C'est quoi le burst

 
Je vois pas ce qui te choque... si l'image est déjà sur le serveur, et que c'est pas du java où il faut 1G de ram, ça va vite  

 
c'est bon ça !
 
tu aurais le lien vers le proxy ?
 
je pense que mes stacks ne seront pas aussi rapides à redémarrer du fait de tomcat

Comme du swap. Donc c'est pas efficace.
Et faut pas perdre de vue que c'est surtout adapté à du stateless donc l'état on s'en fiche.
Et clairement du tomcat c'est pas super adapté pour démarrer rapidement

 
Désolé je peux pas le partager, c'est un repo privé de mon entreprise.  
ça aurait pas répondu à ton besoin, c'est fait pour Kubernetes.  
Le proxy est en go, mais tu peux faire la même chose dans n'importe quel language si tu sais coder un peu.
Une page d'attente, pendant ce temps tu réveil ton container, check quand c'est ready et redirige.

Alors ça peut être un projet passionnant mais ça ne se fera pas avec juste un peu de config, ça peut même être pas mal de boulot en fonction de ce que tu veux faire tourner. Regarde du côté de OpenFaaS qui est même je crois utilisable depuis portainer (en tout cas en mode swarm, en compose je sais pas)). Et de manière générale le concept de FaaS (Function as a Service). L'idée c'est en effet de démarrer le service (et donc le conteneur associé) "à la demande" c'est-à-dire sur requête de l'utilisateur. Ca marche particulièrement bien pour des APIs mais le concept peut être étendu à des pages webs.

Edit : OpenFaaS lui-même c'est quelques secondes à déployer avec pas mal de "Functions" déjà disponibles (bien sûr y aura pas tes conteneurs à toi, faudra au moins les rajouter dans le catalogue... puis peut-être les build un peu différemment pour que ça marche bien dans ce mode-là). Pas besoin de Kube pour ça.

merci pour toutes ces infos
je ne suis pas contre envisager d’autres techno, je vais avoir de quoi m’amuser

Commence par jeter Tomcat

ah

Qqn a déjà trouvé des liens vers des PPS sympas pour présenter l'état de l'art sur la conteneurisation ?
Perso, je n'ai rien trouvé de formidable en l'état, rien qui ressemble à ce que je fais Je passe un temps fou à compiler/recouper/vérifier différentes sources en faisant gaffe aux dates de punlications.
Je suis sur le point d'en finaliser un pour le taf, j'aimerais voir si je n'ai rien oublié d'important car le domaine à pas mal bougé. Si on lit des docs/bouquins/articles d'il y a 2 ans voire même 1 an, ce n'est plus forcément juste aujourd'hui vu que certains trucs ont fait de l'ombre à d'autres, d'autres ne bougent plus, certains projets sont rachetés/consoliés avec ce que fait Red Hat ...

C'est un métier

Je sais bien que dans toutes les COGIP, faire des PowerPoint à la chaîne remplis de pipotron, c'est le métier de pas mal de monde
Moi, je suis novice mais j'ai trouvé une belle police que j'ai mis partout. Allez, je suis sympa, je partage, cela s'appelle "Comic Sans MS"
EDIT :

Dites les pros, j'ai encore besoin de vos lumières.
J'essaie de construire un container avec java, et d'ajouter le path de java au path.
Sauf que je veux que ça soit pérenne, et donc que ça puisse suivre les évolutions de versions.
 
j'aimerais donc que mon JAVA_HOME puisse être interprété à partir d'une commande ls, mais je n'ai trouvé AUCUN moyen de le faire..
J'ai tenté  
export JAVA_HOME=`ls -d /usr/java/*`
ENV PATH "$PATH$JAVA_HOME/bin"
mais ça marche pas.
J'ai tenté avec $(ls -d /usr/java/*) ; mais pas plus de succès...
 
Même un ENV JAVA_HOME $(ls -d /usr/java/*) ne m'interprète pas le contenu, je me retrouve avec un PATH à

 
Il doit forcément me manquer un truc, mais quoi?
 
Merci pour vos lumières

Pourquoi ne pas juste changer l'image de base lors d'une mise à jour ?
My two cents

Je ne crois pas que $PATH accepte le globbing.
 
BTW, tu n'as pas un update-alternatives pour java/javac ?

Tu installes java toi-même ou tu utilises une image java comme base?

Je ne saisis pas ce que tu veux dire.. Si je mets à jour mon image, du coup j'aurai 2 versions de java?
Mais j'avoue que j'ai encore du mal à considérer les images comme des trucs qui peuvent bouger, dans ma tête c'est immuable
 

Non malheureusement, le CentOS que j'utilise est TRES limité (à dessein).
 

J'installe moi même avec le tgz de chez m'sieur Oracle et je me base sur une image CentOS très très light.

Pourquoi ne pas partir d'une image genre "openjdk:8-jre-alpine" ou "openjdk:8-jre-slim"

https://hub.docker.com/_/openjdk

Salut,
 
J'ai une nouvelle problématique à vous exposer .
 
Dans le cadre du dev d'un module NodeJS j'utilise Docker pour tester mon module et avoir une base Postgres dédiée.
 
Mon docker-compose actuel (y'a encore 2/3 trucs qui ne me plaisent pas) :

 
Et ma problématique est : j'aimerais que la VM "sequelize-middleware" se stop automatiquement dès que les tests sont finis (actuellement je fais Ctrl+C mais d'un point de vue praticité on a vu mieux ).
 
Si vous avez des idées...
 
Merci

Attention avec le terme "VM"
 
Comment lances-tu l'exécution de ces services ?

j'avais pas mieux que le terme VM en tête . Je me disais que dire image ce n'était pas mieux .
 
je fais "docker-compose up"

Le plus simple, c'est de définir JAVA_VERSION comme une variable de construction de ton image (ARG).
Tu pourras la récupérer dans une variable d'env et t'en servir pour construire le PATH, voire même pour automatiser la récupération/extraction de l'archive.

Enleve `yarn test --ci --coverage"` de ton compose puis lance tes tests comme ça:
 
docker-compose up -d
docker-compose exec sequelize-middleware "yarn test --ci --coverage"
docker-compose down
 
 
Btw, si je ne me trompe pas, cette façon de faire est dans la doc de docker-compose, donc rtfm

 
 
Outre le fait que ça ne fonctionne pas (mais ça ce n'est pas bien méchant )  :  

 
ça m'oblige à lancer 3 commandes là ou actuellement j'ai juste à faire un ctrl+c (puis flèche haut pour relancer les tests)

Ça ne fonctionne pas sans doute car ton container a déjà terminé son exécution.

Devrait être ta procedure.
 
Après tu lance les tests comme tu l'entends. Tu peux appeller sequelize depuis une image, ou directement depuis ta machine, ou créer un docker-compose pour lancer les commandes sequelize depuis "command: bash -c".
 
Dans tous les cas, la méthodologie la plus simple est de séparer la mise en place de ton environment de test de leur execution, là tu mélange les 2.

En fait mon idée initiale et de ne pas avoir de postgres/nodejs/etc sur ma machine mais que tout soit dans docker.
 
Et que ce soit  "automatisé"/simple d'utilisation. Si ce n'est pas le cas je gérerais autrement (comme je fais déjà sur d'autres projets).

J'ai bien compris, et tu fais bien.
Ton projet c'est du js ? Pourquoi ne pas créer de targets appropriées et utiliser npm ? https://docs.npmjs.com/misc/scripts
Edit: ou yarn: https://classic.yarnpkg.com/en/docs [...] run-script
 
Il n'y a pas plus explicite qu'un `npm test`.
Et tu souhaite préparer l'environnent de test mais lancer des tests différents manuellement ? `npm pretest` te lancera ta db et te générera tes seed.

npm ou yarn c'est la "même chose", dans les 2 cas ça lis le package.json.
 
Par contre si je comprends bien dans ton cas si je fais "npm test" (ou yarn test peu importe) ce sera sur la machine hôte et non sur l'image/container Docker et c'est ça qui "m'ennuie" car ça m'oblige à :
- avoir npm/yarn sur la machine  
- ouvrir le port postgres à mon localhost
 
ça reste une solution acceptable mais je me dit juste "est-ce qu'il n'y a pas mieux"

Mais tu es censé être sûr ta machine de development de toute façon non ?
 
Sinon si tu veux VRAIMENT lancer un node depuis docker tu peux toujours `docker run node npm test`

Je suis effectivement sur ma machine.
 
Je me fait sûrement chier pour rien, ça je n'en doute pas .
 
docker run node etc peut effectivement être une solution...
 
Merci en tout cas pour tes pistes .

C'est quoi l'idée de base ?
 
Vérifier le code avant de le pousser sur un repo git ?
 
Faire de l'intégration continue avec un ordonnanceur ?

Passque je veux pas. C'est pour un projet, et le truc est d'utiliser la même image de base pour tous les containers.
 

Oui, j'avais vu cette solution, et je crois que c'est la meilleure effectivement. Merci!

 
Vérifier le code avant de push (même si le code passe sur un CI une fois push).

Voila, c'est ce que j'avais en tête en écrivant le message précédent. Mais ça n'a pas l'air de te convenir.  
En voulant avoir la meme image pour tous les containers, tu te confrontes à sa maintenance pour tous les containers.  
Alors que si tu prends les images ci dessus, elles sont déjà maintenues, optimisées, et prête à l'emploi et souvent certifiées Docker.

Oui mais c'est.. Contractuel dirons-nous. Je dois partir d'une image Centos mini mini faite par le partenaire.
Du coup c'est nul parce que le moindre truc que j'ajoute me ramène un million de dépendances qu'il faut que j'aille chercher à la main, mais bon.. C'est comme ça.

Effectivement pas foufou le contexte