search

jmMeessen / devbox

Building a portable docker based developer toolbox
12 stars 6 forks source link

le mettre dans un docker / put in a docker? #43

Closed changemenemo closed 7 years ago

changemenemo commented 8 years ago

Bonjour Jean-Marc, Comme j'ai vu que tu étais bruxellois je me permets de t'écrire un peu plus proprement que les habituelles conversations de github et en français. As-tu abandonné le projet de le mettre dans un docker que tu l'aies mis sous forme de source et non pas sous la forme d'un dockerfile déjà ? J'étais heureux de trouver ton repo car ça fait longtemps que je cherche une devbox avec une présentation graphique et le mieux est effectivement sous x2go, qui a été mis à jour d'ailleurs depuis la création de ton repo. Tu n'as pas mis quels outils de départ de dev tu avais mis dans ton container également même si l'on peut le lire dans le dockerfile, et également tu n'as pas précisé si tu avais changé le DE ou bien si c'est le DE debian d'origine(même si je sais qu'on peut le changer)... Ca serait chouette si tu pouvais le mettre sur le hub de docker mais donc pour ça il faut le compiler jusqu'au bout. Je le ferais bien moi, mais je ne suis pas encore au point au niveau de la composition des dockerfile etc, pour le moment j'essaie de maitriser l'entièreté des concepts de gestion des docker, donc si tu pouvais rendre la tâche plus facile des petits néophytes, ça serait cool. Sachant que de toute façon l'utilisation de docker tend à s'uniformiser et donc plus besoin réellement de faire des sources et de compiler soi-même. Merci d'avance de ta réponse P.S.: pour la diminution de ton image, il faudrait sans doute rajouter des apt autoremove et clean pour supprimer les sources apt, ce qui prend le plus de place finalement.

changemenemo commented 8 years ago

by the way comme tu utilises wheezy et pas jessie, tu n'as pas fixé je pense ton apt-get et tu te retrouves avec ceci comme erreur pour la compilation: ---> Running in e067d6e0274e Executing: gpg --ignore-time-conflict --no-options --no-default-keyring --secret-keyring /tmp/tmp.IKJzIJS7st --trustdb-name /etc/apt//trustdb.gpg --keyring /etc/apt/trusted.gpg --primary-keyring /etc/apt/trusted.gpg --keyring /etc/apt/trusted.gpg.d//debian-archive-jessie-automatic.gpg --keyring /etc/apt/trusted.gpg.d//debian-archive-jessie-security-automatic.gpg --keyring /etc/apt/trusted.gpg.d//debian-archive-jessie-stable.gpg --keyring /etc/apt/trusted.gpg.d//debian-archive-squeeze-automatic.gpg --keyring /etc/apt/trusted.gpg.d//debian-archive-squeeze-stable.gpg --keyring /etc/apt/trusted.gpg.d//debian-archive-wheezy-automatic.gpg --keyring /etc/apt/trusted.gpg.d//debian-archive-wheezy-stable.gpg --recv-keys --keyserver keys.gnupg.net E1F958385BFE2B6E gpg: requesting key 5BFE2B6E from hkp server keys.gnupg.net gpgkeys: key E1F958385BFE2B6E not found on keyserver gpg: no valid OpenPGP data found. gpg: Total number processed: 0 ERROR: Service 'devbox' failed to build:

jmMeessen commented 8 years ago

Bonjour,

Effectivement c'est plus facile en français. Je dois avouer que cela fait un bon bout de temp que je n'ai plus travaillé sur ce projet. D'autres projets ont pris le pas. Je devrais le rafraîchir. Le défaut du système c'est qu'il a besoin de pas mal de mémoire pour bien fonctionner. J'en suis un peu à cours sur ma workstation. Je sais que mon compère, @dduportal a encore fait quelques expériences sur le sujet mais je ne sais pas où il en est.

Je ne crois pas que la solution soit suffisement mûre que pour être poussée telle quelle sur Dockerhub. Si tu as un peu de temps et des idées, n'hésite pas à les proposer.

dduportal commented 8 years ago

Bien le bonjour !

J'ai effectivement joué récemment sur le sujet, avec des résultats toujours aussi fonctionnels. Challenge actuel: trouver une solution de partage d'écran la plus "portable" possible.

X2Go est pratique, mais trop contraignant encore, d'où une orientation sur VNC, avec un client en HTML5, afin de ne requérir qu'un navigateur internet. J'ai déjà joué avec noVNC qui est déjà très réactif: https://github.com/dduportal/devbox/tree/vnc-html5-update

J'ai également découvert (https://guacamole.incubator.apache.org/)[Apache Guacamole] qui fait également SSH, récemment, qui combiné avec https://github.com/jeroenpeeters/docker-ssh pourrait être très pratique !

Je fait une update de cette image de base dans une PR dans la journée pour aider :)

changemenemo commented 8 years ago

je ne sais pas comment vous arrivez à compiler ce docker mais clairement y a un problème.... apt-get -qy autoremove && apt-get -qy purge && rm -rf /tmp/* /var/lib/apt/lists/* /var/cache/* /opt/idea-*' returned a non-zero code: 100

changemenemo commented 8 years ago

normalement je devrais avoir un build succesfull à la place

jmMeessen commented 8 years ago

En effet :-( Il y a une erreur qui n'est pas juste. Je vais depiauter la commande pour déterminer ce qui s'est cassé.

changemenemo commented 8 years ago

je pense que ce sont les apt qui foirent et comme il a une erreur à ce niveau là il ne continue pas le build

changemenemo commented 8 years ago

désolé jj'aurais bien regardé moi mais il me faut plus de tmeps car je debug deux autres dockerfile en ce moment

jmMeessen commented 8 years ago

Je regarderai cela ce soir. Il y a une erreur plus haut : le download de la clé PGP pour le apt semble avoir raté.

changemenemo commented 8 years ago

oui voilà c'est bien ça

jmMeessen commented 8 years ago

J'ai poussé un quickfix mais je reste perplexe. En coupant la grande commande en deux, le build fonctionne. Je vais investiguer dès que j'ai un peu plus de temps.

Par curiosité @boistordu , tu utilise quel host pour Docker ? Combien de mémoire est allouée ?

Il y a aussi un petit glitch qui est apparu dans les tests: ils ne sont plus portables (à cause des différences de mapping de volume). Il me semble que c'est induit par les différences de comportement du client Docker pour OS-X

changemenemo commented 8 years ago

Désolé pour le la réponse tardive mais j'ai eu énormément de boulot en ce moment. Moi j'utilie un server ubuntu 16.04.1 avec un i7-4790k et 32GO de mémoire RAM + des host docker sur chacune de mes machines de productions windows où il ya minimum 16GO de RAM et où donc en fonction des besoin j'alloue ce qu'il faut en mémoire. Mais de toute façon principalement les containers sont utilisés et activés à partir du server. Mais il y a plusieurs vm windows qui tournent dessus et plusieurs container aussi donc les 32G sont déjà bien rentabilisés.

J ai build avec succès la devbox hier je vais commencer à l'utiliser aujourd'hui.

Je suis pas fan de votre idée de faire du novnc etc. Les vnc sont fait pour de la présentaiton, j'ai utilisé plein de docker vnc et y a systématiquement plein de bugs si vous n'activez qu'un process de vnc en plus de quelques programmes sans loadé un système entier comme ubuntu avec les variables d'environnement qui vont bien etc. Vous aurez des soucis avec chromium et avec pleins d'autres programmes parce que des variables d'environnement manqueront. Je suis d'avis que tout ce qui se passe sur les browsers est mauvais parce que je trouve que c'est les plus mauvais programmes qui soient avec fuites de mémoire, mauvais garbage collector etc.... Donc je peux comprendre l'envie de diminuer la RAM nécessaire pour le container mais normalement on est tous conscient que de toute façon une devbox prendra énormément de RAM par rapport à tous les IDE comme intelliJ etc et honnêtement je préfère un programme comme x2go où je sais que la connection est sécurisée et où il y aura pas de fuite mémoire par rapport à un browser où la mémoire n'aura de cesse de s'agrandir au fil du temps.

changemenemo commented 8 years ago

Je comprends bien aussi le fait de faire make gui etc mais ce serait quand même cool de pouvoir lancer ce container comme un autre docker donc avec docker run --name devbox -p 42200:22 -d devbox ou même en montant un volume. Parce qu'on peut aussi imaginer le usecase comme pour moi, qu'on le mette sur un server ou un vps et qu'on le fasse tourner à partir de là, sachant qu'on peut ouvrir autant de bureau que l'on veut avec x2go.... Enfin moi j'ai du mal à utiliser la philosophie du make gui etc là en l'occurence comme il 'ny a pas de mot de passe spécifié dans le dockerfile il refuse la connexion. je suppose que votre technique du makegui demande un mot de passe?

dduportal commented 8 years ago

Bonjour @boistordu !

Cela fait beaucoup de choses d'un coup :)

changemenemo commented 8 years ago

Moi il me semblait justement avoir compris que la connexion x2go via une clé ssh était une connexion du coup sécurisé de bout en bout mais peut-être que je n'ai rien compris ssh, quoiqu'il en soit je ne vois pas à quelle partie x2go délivre en clair des informations mais peut-être que je me trompe hein.

Pour la comparaison avec les VM, jke pense pas avoir parlé de multiplier les processus principaux. En soi on a juste besoin de ssh et de l'interface graphique.... ET je suis tout à fait d'accord qu'il faut limiter les process au plus petit dénominateur commun, c'est vraiment pas là mon problème. Je parlais jsute d'expérience avec d'autre docker par rapport à novnc que des problèmes de variables d'environnement se posent. Rien empêche de supprimer quantité de process de l'install d'ubuntu de base, ça n'est pas du totu en lien avec les variables d'environnement. ou bien je me trompe de nouveau? Quoiqu'il en soi je peux comprendre, vraiment je m'oppose pas du tout sur un point de vue technique ou idéologique linuxienne je suis entièrement pour tout ça. Moi je pars du point de vue de l'utilisateur. le docker est quelque part un nouveau standard en lancement, et quelque part en informatique je suis pour les standards contrairement au début de l'informatique. Donc c'est vrai que quand vous voyez ce que l'équipe de dev de docker essaie de mettre en place un certain standard d'utilisation me semble-t-il ? donc quelque chose plus du style comme je disais docker run .... Rien ne nous empêche aussi de mettre l'interface en silence dans le container et de l'activer via une commande de type docker exec devbox trucmuche. si? D'ailleurs il me semble qu'il n'y a pas réellement de bureau qui est chargé au démarrage de docker mais bien juste à l'activation d'une connexion x2go non? Désolé c'est vraiment au point de vue usercase que je me place et du standard que le user lambda va lire dans les docs de docker etc et donc aurpès desquels il va être habitué à une certaine mise en forme.

La philosophie docker je la vois comme ça en quelques mots:
-supprimer la couche virtualisation matérielle des VMs -garder la sécurité que représentent les VMs -garder le comfort de la séparation des données, environnements qu'offrent les VMs -offrir un standard d'utilisation et d'interface pour le user lambda de sorte que tous les containers aient une même mise en forme de build, run, start pour justement éviter comme je le disait jean-marc dans sa présentation du container, un apprentissage nécessaire pour installer et démarrer le truc et offrir une solutio nstandard de devbox à tous.

Et c'est vrai que du coup quelque part le make gui etc même si je comprends tout à fait l'intention de départ du small is beautiful, le truc sort de l'ordinaire quelque part et ça sort du coup du standard que j'aimerais bein pouvoir utiliser dixit la doc de docker et d'autres IT manager que je connais qui étaient fort énervés au début de docker de la non uniformité des container sur leur principe de lancement etc. Et puis ne peut-on pas utiliser les docker DAB dans les dockerfile justement ? Il me semblait que les possibilités des dockerfile étaient toujours en expansion et il y avait finalement peu de limites à ce qu'on pouvait effectivement faire. Mais à nouveau vous êtes certainement plus expert et à même de savoir ce genre de choses que moi, à nouveau comme je vous le dis je me place du user lambda qui a me semble-t-il besoin d'une uniformité pour un même système . Ce que j'adorerais ce que dans les cours d'informatiques ils puissent aussi utiliser ça mais à nouveau même si vous faites un bon readme, ça serait queqlue part contre productif car l'étudiant en informatique ne va pas y comprendre quelque chose si d'une part dans la doc de docker il est indiqué quelque chose et que vous utilisiez quelque chose d'autre.

Mais bon tout ça n'est que mon point de vue d'utilisateur lambda .

Après pour ce qui est du volume monté, à nouveau je me place du user lambda, je comprends pas très bien en quoi le fait de monter un volume d'un dossier du host est une forme de dépendance. NE parle t on pas ici d'une devbox? Donc il me semble que l'on va quand même créer des projets et des fichiers au sein de cette devbox? Donc le moyen le plus aisé et facile c'est quand même de monter le volume du dossier personnel pour les stocker et les récupérer, non? Or monter une VM pour ça est beaucoup trop fastidieux et inutile et c'était justement l'intérêt de docker aussi, pouvoir accéder directement à certains fichiers et ne pas passer par la virt I/O des vm pour l'accès disque même en cas de dossier partagé.

Pour ce qui est du NoVNC je peux pas me prononcer. Toutes les expériences faites avec les docker novnc sur le hub se sont retrouvées nullissimes, soit elles ne fonctionnaient pas (les browser ne faisaient pas la connection), soit une série de programmes étaient impossibles à utiliser alors que c'était des novnc prévu pour faire l'usage desktop. Et par rapport aux browser peut-être que vous avez raison quand vous dites que c'est l'endroit le plus sécurisé de la machine mais en attendant c'est quand même à travers les browser que la plupart des failles de sécurité se jouent à travers des codes javascript dans les pages etc. Même des séries grand public en font l'apologie (je parle de ces failles) comme Mr ROBOT. Après je ne veux pas vous contredire, vous en savez certainement plus que moi mais force est de constater que la plupart des failles mis à jour ces dernières années c'est à travers les browser + le fait que comme vous le dites les pages ont des scripts mal écrit en leur sain mais ça veut dire aussi qu'il y a pas de garde fou dans les browser non plus et qu'on se cantonne du coup à exécuter le script qui se trouve dans la page..... Après si vous me montrez que ça marche dans tous les use cases, cool alors pas de soucis j'en serais très content car vous seriez à peu près le seul sur le hub et sur github à l'avoir fait fonctionner sans problèmes.

Pour le build apt j'ai pas regardé en détail j'ai pas fait gaffe honnêtement. Et l'idée de faire un RUN ddans le docker par groupe de choses à installer ou par items sera certainement mieux, plus clair et plus facilement modifiable par la suite.

Quoiqu'il en soit, tout ce que je disais là n'était en rien aggressif ni quoi que ce soit, je sais que parfois ça peut sembler comme ça donc je préfère prévenir. Après mes objectifs d'une devbox : -utilisation standard de docker pour que ce soit accessible à tout le monde sans lire un readme -sécurisation -accessibilité des fichiers directement depuis l'explorateur de l'host -interface graphique de préférence pour le développement -petite utilisation en mémoire pour ce qui est de la visibilité de l'UI je m'en fous de comment ça fonctionne du moment que ça fonctionne dans tous les USE CASE

dduportal commented 8 years ago

Ah ah, les délices de la communication écrites :) Pas de problème @boistordu je n'ai pas pris comme une agression, ni sous entendu aucun problème de compétences.

J'entends bien le besoin "use case", mais on ne peux pas apporter de solution faciles à un challenge qui est compliqué, par essence même. La seule solution est l'apprentissage. Docker apporte un apprentissage linéaire, sans réel "pic".

En l'occurence, NoVNC (client VNC HTML5) permet d'éviter tout README, mais satisfaire tous les USE CASE des workstation est un objectif vraiment trop ambitieux:

Et ce n'est qu'un début :) En analyse chiffrée sur les clients de ma boîte, on a déjà la moitié des personnes qui n'ont pas les droits admin sur leur machine, mais peuvent demander l'installation de Docker ou Virtualbox + Vagrant en avance => X2Go est hors de question dans ce cas par exemple.

D'où ma position de "simplifier": le HTML5 est une plateforme de choix, universelle et tout aussi sécurisée que le reste car supportant de très bon standards d'encryption. La comparaison avec SSH n'est au final pas utile. La sécurité est une histoire de "couches". Avoir SSH mais ne pas crypter son disque dur avec ses clefs RSAs, ne pas changer de clef ni de passphrase mensuellement, ne pas surveiller ni mettre à jour les versions de ses logiciels pour éviter les vulnérabilités (exemple: https://www.cvedetails.com/vulnerability-list/vendor_id-120/SSH.html ) sont bon nombre d'exemple qui mettent SSH au même rang que HTTPS: il y a une balance juste à trouver. En l'occurence, HTTPS si besoin. (N.B. en local je m'en contrefiche: je bloque l'accès du guest vers le host. Le sens opposé n'est pas utile :) )

Concernant Docker, il n'a jamais été question de standard universel, à part https://www.opencontainers.org/ (une tentative d'unifier la partie "runtime" des containers). Un standard doit être traduit par des RFC ou équivalent comme le HTML5 est, sinon ce n'est pas un standard, mais une approche courte terme. Je prendrais comme exemple TCP ou HTML qui ont plusieurs décennies de maturité pour démonter qu'ils ont survécu aux "changements". Attention donc aux impressions données par les articles de blog, il y a une forte communauté "Anti Docker" qui tente de faire passer des messages fallacieux ;) => DAB est encore expérimental mais l'idée est de fournir un "pack" de services, comme les docker compose. Mais au lieu d'être connu côté client (=> USE CASE, on ne veut pas faire télécharger docker-compose à l'utilisateur final), il est côté serveur Docker.

Bref, je pense qu'avoir l'occasion d'en parler autour d'une bière /café serait un bon moment d'échange, en attendant, je vais proposer mes changement sur mon dépôt et tout test ou contribution est le bienvenu !

changemenemo commented 8 years ago

Bon entendons nous déjà sur ce que je délimité par use case. A ma connaissance toutes les machines vendues actuellement pour les particuliers sont du 64 bits.
J évacue donc les nas, raspberry et autres.
Docker à ma connaissance à été fait pour être indépendant dans une certaine mesure de l architecture en place donc normalement on ne doit pas se préoccuper des vt x et vt d et des kernels charges donc des os. Si je me trompe il faut me le dire et me montrer à quel endroit precisement.

Quand je parle de standard je parle pas de standard effectués par le monde du rfc. Je parle du standard mis par l entreprise pour sa plate-forme, parlons de conventions si vous préférez. Au même titre qu il y a les conventions java, c est pas parce que ça fonctionne sans les conventions que pour ça on ne les utilise pas.
Et honnêtement je connais pas la communauté anti-docker, tous ceux que je connais ne m en parlent qu en bien.

Puis je être prosaïque ? Si oui, en partant de ces deux points de départ, qu est ce qui nous empêche de faire en sorte de starter le container avec une mise en forme de docker run... Y a t il une limitation qui ne vous permet pas de le faire parce que telle ou telle fonctionnalité ne serait alors pas incluse ? Si oui laquelle ?

Si on commence par là, je pense que je pourrai commencer à comprendre le problème de la mise en place qui pour moi me semble pourtant simple mais moi je suis du style de musique inspirer du code dans un premier temps d autre dockerfile. Si on commence pas à m expliquer quel est le problème de ce qui est adopté en général, alors je comprends pas. Que ce soit plus facile via votre biais c est très bien mais ça répondra quand même pas à ma question.

A partir de la j aurai une meilleure compréhension. Et ça peut bien entendu se faire autour d une bière:) mais au moins comme ça on aura un démarrage de discussion.

En tant que tel je peux pas faire adopter cette solution avec make et make gui a moi même où à mon entourage de travail et autre.
Le usecase du lambda pour moi C est: A partir du moment que le user est dans le groupe docker et qu il connaît les commandes docker de base, Faire un docker build. -t truc Ou docker pull truc/truc Docker run name muche... Truc

Voilà, en soi rien d extraordinaire, le protocol le plus basique qui soit que la plupart utilisent justement

dduportal commented 8 years ago

Je ne souhaite pas prendre avis pour mon compère @jmMeessen mais voici ma cible de travail, basée sur mes statistiques d'usage d'une devbox dans mon environnement professionnel:

=> Ces statistiques étant effectué sur des personnes de différents continents, je les considère comme suffisamment représentatives.

=> Mes priorités sont donc:

=> VT-x est requis afin d'exécuter une VM 64 Bits (boot2docker ou Docker4Mac / Linux). Même si le processeur et l'OS sont déjà en 64 Bits.

Je considère que le partage de dossiers avec l'host, non auto-managé par docker est une mauvais pratique qui rend l'image dépendante de l'host et donc NON portable, allant donc à l'encontre de l'usage de Docker.

Certains problèmes devant être adressés si on "bind mount" quelque chose avec le host:

=> Make était une solution valable il y a un an (docker-compose non stable, devbox encore trop dépendante de l'host mais déjà fonctionnelle) dans notre cas d'usage. Make est multi-plateforme, multi-architecture et nous sert à abstraire à haut niveau le cycle de vie de la devbox.

=> A partir d'ici, mes futurs implémentations seront basées soit sur Make, soit sur docker-compose, soit sur un mix des deux. Je laisse maintenant la main à mon compère car nous sommes sur son espace Github et je ne souhaite pas "hijacker" plus cette issue.

Je vous rappelle que nous faisons ce projet pour notre propre plaisir, nos propres intérêts et notre temps libre. Aucun problème à ne pas être d'accord, mais ce sont nos choix dans nos contextes qui ont même valeur que les votre. Attention donc aux formulation écrite pouvant être blessantes car dans le registre "aggressif passif".

Si Make ne vous convient pas, n'hésitez pas à forker le projet, c'est la force de Github et du libre: vous pourrez ainsi être maître de votre propre devbox, adapté à vos besoins spécifiques

dduportal commented 8 years ago

N.B. technique: avoir un point d'entrée "docker run" simple, qui va lancer le docker-compose est une approche possible dans le futur qui pourrait satisfaire la demande initiale.

Mais d'abord docker-compose, et ensuite docker containeur embarquant le docker compose.

C'est une approche que nous utilisons ici: https://www.cloudbees.com/get-started pour info.

changemenemo commented 8 years ago

J'ai bien compris votre argument concernant le partage de fichier host<->VM de docker qui montre bien les problèmes que du coup vous vous posiez sur la question donc ça c'est très cool de votre part de l'avoir expliqué plus en détail que précédemment. Après ce n'est qu'une feature donc si vous imaginez un autre système pour le transfert de fichier c'est tout aussi possible du moment que ce soit relativement simple.

Après je ne comprends pas l'argument par rapport au make vs un bête dockerfile mais vous pourrez peut-être être plus à même de me l'expliquer autour d'un verre :)

A nouveau, vraiment, il ne faut pas prendre ce que je dis pour quelque chose agressif mais si je ne comprends pas quelque chose je vais fatalement insister sur ce point pour essayer de le comprendre. Donc c'est vraiment dommage que l'on ne se comprenne pas là-dessus.

En ce qui me concerne, je n'ai certainement pas les compétences intellectuelles pour réaliser cette tâche c'est bien pour ça que je discute et prends le point de vue ici du user et pas du dev.

changemenemo commented 7 years ago

@dduportal @jmMeessen Alors juste pour info je mets le lien de la devbox qui es tencore à peaufiner mais elle est sensé fonctionner sur toutes les version de docker-engine à jour et ce même sur un rasperberryPi et comme demandée elle est équipée avec novnc. Et franchement je vois pas ce qu'il y avait de compliqué à utiliser une la version standardisée des dockerfile. C'est quand même bien plus simple et bien plus uniforme. docker-devboxnovnc