Reprise du message précédent :
Oui, pour du job, Mesos/Marathon c'est le plus adapté.
Tu peux regarder du côté de Nomad de Hashicorp aussi.
 
Rancher c'est top, tu peux creuser, mais ça ne correspondra pas à ton type d'utilisation si c'est la seule que tu recherches : ça ne gère pas (à ma connaissance) le mode batch, c'est plutôt très orienté micro-services.

Pour l'instant j'utilise rancher pour la faciliter à déployer un cluster, je pense que je vais le garder, ça sera utile à mes collègues d'avoir une interface pour quand je prends des congés    
 
- J'ai tester marathon ce matin, c'est pas mal, mais ça ne correspond pas à mon besoin, ça relance les jobs automatiquement, je me suis planté sur la définition de "long job" pour eux ça veut dire que ça tourne en permanence.
- Je teste chronos mais pas sur que ça correspond  
- Je vais me pencher sur nomad, merci  

Pour du job c'est plutôt chronos. Marathon c'est pour du long standing.

Salut et merci pour tes exemples !
Je mets aussi ça en place en ce moment.
Une précision : dans un .gitlab-ci.yml, tel que je le comprends si on se base sur une image classique (debian:8 pour l'exemple) donc sans docker installé, mais qu'on utilise la ligne

, logiquement on devrait avoir accès aux commandes docker non ?
En fait dans mon cas si l'image de base de mon .gitlab-ci.yml ne contient pas elle-même docker, j'ai une erreur du type

Bonjour, j'utilise un peu docker sur mon NAS, mais je suis loin d'etre expert.
 
J'ai un certains nombre de container qui tourne en quasi permanence.  
 
Les containers ont été créé une fois pour toute et depuis je le relance à chaque démarrage avec docker start nomducontainer .
 
La je vais avoir besoin d'en recréer certains.
Comment je peux retrouver la ligne de commande exacte (avec tous les les arguments) qui avait servi à créer un container donné ?

Tu peux la reconstituer avec un "docker inspect", faudra chercher les params et la recréer toi-même par contre.
 
Et pour ne pas te faire avoir la prochaine fois, met toi à docker-compose

OK, j'avais bien vu avec inspect que je pouvais tout retrouver, mais j'espérais trouver une méthode plus directe. Tant pis, je vais faire çà (et me mettre à docker-compose )

Au passage, il y a maintenant pas mal de temps ils ont ajouté l'option --restart pour, entre autre, relancer le container au démarrage (--restart=always)

Il vaut mieux privilégier unless-stopped plutôt que always

Puisque tu me suggère aimablement d'utiliser docker-compose....
J'essaie de transposer dans docker-compose mes containers actuellement lancés avec docker run...
 
J'ai une erreur à la con:  

 
Mon fichier docker-compose est là:

 
 
Je suppose que c'est une erreur à la con dans la syntaxe de mon fichier YAML , mais je ne suis pas suffisamment familier avec ce langage pour l'identifier.
Une idée ?

Je réponds depuis mon téléphone donc je peux pas tester, mais j'ai l'impression que c'est un problème d'indentation.

Tes 4 dernières lignes concernent jeedom et doivent donc être indenté "sous" jeedom. Je pense qu'il leur manque un cran d'indentation.

C'est ça. Merci.

( C'est nickel docker-compose)

Mais il est partout...  

Drapal et help
 
Pour la première fois je veux lancer un contrainer qui utilise des fichiers en non des folders.
 

 
Dans mon .yml (je ne fais que du docker-compose) :  
 
Si je mentionne dans mes volumes
- /my/config.propertiesopt/autosub-bootstrapbill-master/config.properties et que le fichier n'est pas présent avant le lancement du container, je me retrouve avec un folder config.properties au démarrage du container, et il se relance en boucle.
 
Si je crée (touch) un fichier vide avant le lancement (avec les bons droits), le container ne démarre pas, tombe en error et me dit que mon fichier n'est pas un directory (merci, c'est le but ).
 
... je ne comprends pas d'après la doc, on peut utiliser un fichier ou un directory, comme on veut, tant que le path est absolu (ce que j'ai fait).
 
J'ai essayé en ligne, avec docker run et même combat
 
C'est arrivé à quelqu'un ?
 
 

La seule fois (de mémoire) où j'ai utilisé un fichier, c'était pour faire du "docker in docker", fallait lier le fichier docker.sock, et ça fonctionnait très bien

Ben si ta source (la partie gauche de ton volume) n'existe pas, docker ne sait pas si tu veux un répertoire ou un fichier. Donc il considère que tu veux un répertoire (cas le plus courant).
 
Par contre je suis surpris du comportement avec le touch. Chez moi ça fonctionne :

 
T'aurais pas déjà créé un répertoire avec le nom du fichier par erreur dans ton image ?

Déjà je vais tester la même chose pour voir
Sinon, oui, au début, je n'avais pas créé les fichiers donc docker/container m'a créé des folders.
J'avais fait un nouveau build mais je me suis peut-être planté et il a gardé les infos dans l'image ...
Je vais aussi tester en supprimant le container.
 
Merci pour les pistes, pas facile quand on débute

Hello,
Encore moi. J'ai abandonné mon image précédente pour d'autres plus adaptées.
 
ET j'ai un problème.
 
docker-compose ne prend pas mon paramétrage du fichier de log :  
 

 
C'est surement la version dans les repository debian qui est super vieille : docker-compose version 1.8.0, build unknown
 
Donc j'ai voulu upgradé ... et la, c'est le drame ...
 
Rien qui marche en suivant ça : https://docs.docker.com/compose/install/
 
Quelque soit la version dernière ou autre, ça ne marche pas.
 
Je fais ça :  
 

 
puis un chmod +x dessus
 
et ensuite, j'ai ça :  
 

T'as du te rater dans le copier coller de la commande, y a des caractères spéciaux importants dedans.
Essaye de comprendre ce que fait la commande et télécharger le à la main depuis les releases de github, ce sera plus simple.

+1 pr rancher

Toi t'avais pas vu la nouvelle page

nan
c t top rancher meme si je suis parti au debut du projet

J'ai découvert docker-machine , bien sympa pour se déployer des labos en un rien de temps

Vous utilisez consul aussi ?
J'aimerai monter en compétence sur la partie à la mode Docker (que je connais un peu, ainsi que swarm) et Jenkins.
Vous avez un bon tutos là dessus ?

j'essaie d'écrire un fichier docker-compose.yml pour monter des containers avec :
 
* nginx comme reverse-proxy
* portainer
* cadvisor
 
à terme j'y ajouterai prometheus et grafana  
 
pour le moment je bloque avec nginx parce que dans le fichier Dockerfile de nginx j'essaie de :
 
* supprimer le fichier /etc/nginx/conf.d/default.conf
* copier mon fichier portainer.conf dans /etc/nginx/conf.d
* copier mon fichier cadvisor.conf dans /etc/nginx/conf.d
 
le résultat est que si je copie les 2 fichiers, seul cadvisor est pris en charge par nginx
 
j'ai essayé de mettre les 2 conf dans un seul fichier et ça fonctionne mais j'aurais préféré séparer les conf
 
c'est possible ? il y a une astuce que j'ai zappé ?
 
je suis parti de là : https://github.com/portainer/portainer-compose
et j'ai juste ajouter bêtement portainer

vaudrait pas mieux configurer nginx en dynamique en fn des containers lancés ?
Comme fait nginx-ingress sur kubernetes

Drap

flag !

C'est pas très vivant ici

Ça a l'air encore très confidentiel en usage perso.
Pourtant les avantages sont multiples.

Je viens de récupérer un Raspberry Pi pour en faire un serveur domotique.
Je veux tout faire en container docker :
- zigbee2mqtt
- broker MQTT (eclipse mosquito)
- serveur Openhab

Eh bien c'est bien plus complexe que ce que j'imaginais  

Mon serveur perso et full Docker, ok je fais ça aussi toute la journée en pro
 
Quelle étape trouve-tu complexe ? je me rends plus compte de la difficulté peut être, il faut documenter la première page avec des exemples je pense...

Ben ça dépends des applis que tu veux faire tourner dedans.
Certaines sont adaptées, d'autres pas vraiment et ça devient du bricolage (plus ou moins propre).

Du coup en environnement pro où tu utilises Docker pour tes propres applis sur lesquelles tu as la main pas de souci, pour les applis "externes", c'est souvent plus bancale.

Tout dépend de l'appli, y'a souvent des applis qui proposent un image docker, à partir du moment ou tu sais quel ports ouvrir et quels sockets partager, en général ça ne pose pas de soucis.
 
J'ai teamcity + teamcity agent, prometheus, gogs entre autres.

bah genre machinalement : je veux un Eclipse mosquitto comme brocker MQTT.
le besoin est simple (trivial).
 
je cherche sur le docker hub.
je tombe sur la distrib officielle gérée par Eclipse fundation    
https://hub.docker.com/_/eclipse-mosquitto/
 
j'installe le package chez moi (bon déjà le tag "latest" a l'air buggé, je suis obligé de spécifier explicitement la version)
je lance le package... qui me pète une pauvre erreur technique sans queue ni tête.
 
Après recherches, j'en déduis que :
- Eclipse ne met à disposition QUE une version x86_64 du package... donc incompatible avec mon archi ARM
- mon docker perso est incapable de savoir qu'il tourne en ARM   .... n'est pas choqué de downloader une image qu'il n'arrivera pas à faire tourner   ... et ne gère pas proprement une image incompatible avec mon archi    
 
ça me semble pourtant être "la base" d'une gestion de containers... ou bien il y a un truc que j'ai loupé

Les containers permettent d'isoler le workload, mais ça ne t'affranchis pas d'avoir des binaires compatibles avec ton architecture. Dans le même style, ton container partage le kernel avec son host, donc tu ne peux pas manipuler le kernel d'un container.

Tu peux utiliser ça pour mosquitto:
 
https://github.com/leojrfs/mosquitt [...] Dockerfile

ça j'ai bien compris.
 
Mais je pensais (naivement) que mon install docker locale connaissait l'archi du host sur lequel elle tourne (ARM dans mon cas), et que par défaut il chercherait à me DL les containers que je pourrai ensuite executé
(j'ai que faire d'un container AMD64 sur mon Raspberry)

c'est justement celui que j'ai récupéré hier soir

Y a beaucoup d'applis qui proposent des images Docker bien bien moisies aussi
Je parle bien d'image "officielles".