Harbor est un registry d’images de conteneurs open source qui sécurise les images à l’aide de contrôles d’accès basés sur des rôles, d’analyses des images à la recherche de vulnérabilités et de signature d’images comme étant de confiance. Harbor a comme but d’aider à gérer de manière cohérente et sécurisée les images sur des plates‑formes cloud comme Kubernetes et Docker.
Dans sa version 2.0 qui vient de sortir, Harbor est maintenant totalement compatible OCI (Open Container Initiative). Ainsi, il permet de stocker les images de vos conteneurs ou tout objet compatible OCI comme les Helm Charts en version 3. L’avantage de cette compatibilité avec OCI est que cela évite de devoir avoir un système spécifique pour chaque type d’objet.
Harbor vous permet donc de stocker vos images privées en local ou d’en faire un cache pour éviter des problèmes de réseau au téléchargement. Il permet aussi de d’analyser des images pour vérifier qu’elles ne contiennent pas de failles de sécurité connues et de vérifier les signatures pour ne distribuer que des images signées.
Nouveautés
OCI
Harbor est maintenant compatible avec le format et les API OCI (Open Container Initiative), ce qui lui permet de stocker n’importe quelle donnée du moment qu’elle est compatible avec cette API. Par exemple, cela veut dire que les Helm Charts et les images de conteneurs sont stockés de la même manière.
OCI apporte aussi un index qui permet de spécifier la même image pour différentes architectures. Cela signifie qu’il n’y a plus besoin de le spécifier explicitement, c’est le client qui choisira ce dont il a besoin en fonction des paramètres définis.
Analyse d’image
Trivy remplace Clair comme outil d’analyse par défaut. Clair reste disponible. Un des gros avantages de Trivy est d’analyser toutes les couches des images au lieu de seulement la dernière couche. Cela permet de trouver des vulnérabilités dans des bibliothèques compilées en statique.
Comptes pour robot
Les comptes pour robot, dédiés à être utilisés dans des scripts ou comme credentials pour tirer des images, peuvent désormais expirer de manière individuelle et non plus uniquement de façon globale et, dans le futur, il sera possible d’avoir le même compte pour plusieurs projets.
Chiffrement
Il est maintenant possible de chiffrer en SSL (d’après l’annonce, j’espère que c’est du TLS en vrai) la communication entre les différents composants d’Harbor.
Webhook
Il est à présent possible de déclencher les Webhooks de manière individuelle et l’intégration avec Slack est fournie de base.
Aller plus loin
- Annonce de sortie (273 clics)
# container compatible OCI ?
Posté par TBTB . Évalué à 1.
Hormis docker quels sont les containers compatible OCI ?
[^] # Re: container compatible OCI ?
Posté par claudex . Évalué à 4.
podman il me semble.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: container compatible OCI ?
Posté par marty314 . Évalué à 1. Dernière modification le 20 mai 2020 à 20:00.
Pour avoir testé podman pour developer une petite appli Django j'ai galéré à monter un simple volume, j'ai abandonné au bout d'un temps mais il semblerait que ce soit mal géré. Habituellement je bosse avec docker-compose en développement / swarm en prod et ça fait le taf plutôt pas mal mais je voulais tester les outils Fedora qui avaient l'air plus basés sur l'OCI
Bises
[^] # Re: container compatible OCI ?
Posté par barmic 🦦 . Évalué à 2.
On utilisait ça pendant pas mal de temps, le passage à un orchestrateur plus complet est assez salvateur. En tout cas quand tu déploie sur plusieurs machines. Rien que la répartition des instances sur les serveurs n'est pas folles avec swarm. Le passage à docker stack ou une alternative, ça demande un effort de s'y mettre mais le retour sur investissement et plutôt pas mal je trouve.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: container compatible OCI ?
Posté par marty314 . Évalué à 0.
Yes il s'agit bien de stack sur un swarm, désolé je me suis mal exprimé.
Pour l'instant k8s m'a l'air un peu trop overkill et en ayant testé podman j'ai été déçu par la gestion des volumes (notamment podman compose) donc même si ça a l'air prometteur et que ça permet de lancer sans root/sudo bah j'ai pas réussi à l'utiliser correctement grossomodo podman-compose avec un PostgreSQL persistant
[^] # Re: container compatible OCI ?
Posté par Psychofox (Mastodon) . Évalué à 2. Dernière modification le 20 mai 2020 à 11:48.
tu veux dire les runtimes ?
podman, rkt, cri-o, containerd…j'imagine qu'il y en a d'autres.
Note qu'il me semble que docker n'est maintenant plus qu'un emballage pour containerd. Alibaba a développé son équivalent : Pouch.
[^] # Re: container compatible OCI ?
Posté par barmic 🦦 . Évalué à 4.
Tu n'a même pas forcément besoin de remplaçant tu peut juste utiliser containerd si tu le souhaite (ça évite d'avoir le deamon docker que certains n'aiment pas).
J'ai l'impression que l'écosystème docker/k8s n'est pas encore arrivé à son niveau de maturité pour être stable (dans le sens ne pas changer l'état de l'art architectural tous les 2~3 ans).
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: container compatible OCI ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
Mais d'un point de vue dev, j'imagine que le gros des concepts et des commandes ne va pas trop bouger, non ?
"La première sécurité est la liberté"
[^] # Re: container compatible OCI ?
Posté par claudex . Évalué à 3.
Tant que tu te limite aux API stables (et pas celle en alpha/beta).
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: container compatible OCI ?
Posté par barmic 🦦 . Évalué à 2.
Du point de vu dev oui, c'est la stack de déploiement qui me donne l'impression de se chercher. Éventuellement la configuration (ce qui est fait avec helm ou kustomize par exemple). L'état de l'art de la manière d'empiler orchestrateur + runtime + dépôt + configurateur évolue évolue pas mal (je dis pas qu'il n'a pas à évoluer, je dis que se tenir à jour demande un travail conséquent et une compréhension relativement approfondie). Et il faut séparer les annonces des réalités, beaucoup d'entreprises font des annonces ou des gens publient des articles, mais sans forcément qu'il y ai quelque chose derrière ou que ça prenne (kubernetes pour des machines virtuelles, il y a plus de gens qui en parlent que de gens qui en utilisent par exemple, IBM annonce des fois des outils pour orchestrer des orchestrateurs,…).
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: container compatible OCI ?
Posté par oau . Évalué à 2.
Bonjour,
effectivement, je suis en plein dedans. Autant je pense que la couche container avec ou sans docker et orchestrateur avec kubernetes est stable et on trouve un kubernetes chez tous les hébergeurs de cloud.
La partie déploiement ne l'est pas du tout. Et pour le moment je ne vois rien qui se détache réellement.
Helm c'est bien pour déployer des applications qui existent déjà. Je le vois comme le apt du cloud. Mais pour déployer sa propre application je trouve ça trop lourd. Il y a terraform dont beaucoup de gens parlent, mais apprendre encore un langage relativement neuf c'est pénible et pas nécessairement pérenne. Je n'ai pas encore regardé kompose ou crossplane mais j'ai un faible pour pulumi. C'est du python et j'aime bien le python.
Après pour une application relativement simple avec 2, 3 services, une base de données, un django, un nginx ce n'est pas forcément nécessaire. Un petit coup de envsubst dans le yaml suffit. Mais il est vrai que ma cicd gitlab qui faisait 20 lignes il y a un an en fait 400 aujourd’hui …
[^] # Re: container compatible OCI ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
"déploiement"
C'est la partie qui exécute les commandes kubectl, typiquement dans un .gitlab-ci.yaml ?
J'ai l'impression aussi que l'installation de kubernetes lui-même n'est pas simple. Par exemple, si on veut se faire un cluster à soi chez un fournisseurs de bare-metal (ovh) ou de VM.
j'ai juste vu passé le nom "Helm".
"La première sécurité est la liberté"
[^] # Re: container compatible OCI ?
Posté par oau . Évalué à 2.
c’est en partie ça, on parle aussi d’infrastructure as code. C’est un moyen de garder une consistance entre une infra décrite avec du code et la réalité.
C’est ce que je fais chez OVH. Kubernetes c’est 3 binaires en go et une base etcd. C’est donc assez simple. À installer et à mettre à jour.
La partie pas nécessairement simple est au niveau du réseau quand on veut bien tout séparer dans différents vlans. Il faut assi bien faire attention aux api qu’on utilise dans ses yaml. Il y a des changements lors des montés de version qui peuvent casser les déploiements. Dans mon souvenir les déploiements ont changé entre la version 1.15 et 1.16, c’est passé de beta à stable. Après c’est juste une ligne à changer dans son yaml. Mais sur le coup ça surprend.
Ensuite il faut aussi installer et donc maintenir un cluster Ceph pour le stockage ce qui rajoute de la complexité et du temps pour faire l’exploitation.
Mais dans l’ensemble ce n’est pas si compliqué que ça quand je pense aux usines à gaz que j'ai dû installer pour "des grands comptes". Ceph est incroyablement stable, simple, cohérent, performant et plein de fonctionnalité. Pour mon utilisation c’est vraiment un point final à la gestion du stockage. Je dirais la même chose pour k8s.
Après je ne propose pas à mes clients de faire la même chose chez eux. Il est tellement simple de déployer un cluster k8s chez google, aws ou azure que je ne suis pas sur que le faire chez soi ait du sens si on parle de simplicité. Par contre niveaux coût par mois pour le moment il semble que c'est quand même bien moins cher de le faire soi-même. On garde aussi la main sur le hardware qu’on utilise.
Avant de partir sur un type de serveur chez ovh j'ai passé un bon mois à tester les différentes offres. Surtout au niveau des disques SSD/NVME. Ceph est particulièrement tatillon sur les disques.
Au final k8s et Ceph ont totalement changé ma tripple vie de dev, de datascientist et d’admin. Avant je faisais 50 % d’admin, 40 % de dev et 10 % de datascience. Aujourd’hui je fais 10 % d’admin, 40 % de dev et 50 % de datascience. Mon unique outil d’admin c’est git. Et c’est un admin de trèèès longue date qui dit ça ;)
[^] # Re: container compatible OCI ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 3. Dernière modification le 22 mai 2020 à 10:18.
Ceph est une obligation pour k8s ou est-ce ton choix ? Et le système de fichier de hadoop ?
J'avais vu qu'il gérait aussi iSCSI ou iSER.
Je n'ai encore vu si la modes des clusters k8s était de séparer serveur de calcul et serveur de fichiers (de volumes, SAN…), ou bien de faire n machines identiques, avec partage distant ou non des fichiers par une techno d'accès réseau.
"La première sécurité est la liberté"
[^] # Re: container compatible OCI ?
Posté par oau . Évalué à 2.
Ceph n'est pas une obligation mais avoir un stockage partagé oui. Tu peux utiliser autre chose. HDFS je n'ai jamais utilisé. Mais vraiment ça ne me donne pas envie, de loin ca à l'air particulièrement lourd. Sur la ML de ceph beaucoup de gens cherchent à remplacer HDFS par ceph.
[^] # Re: container compatible OCI ?
Posté par barmic 🦦 . Évalué à 3.
Nous on en utilise pas. En quoi c'est une obligation ?
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: container compatible OCI ?
Posté par oau . Évalué à 1.
Pour pouvoir garder tes données ? Si j'installe un elastiksearch je veux pouvoir conserver mes données si la machine disparaît pour une raison ou une autre. Si je n'ai pas de fs partagé les données sont en local. Ou dans un stockage éphémère qui disparaît quand le pod redémarre ou dans un Persistent Volume local qui disparaîtra si la machine disparaît. Qu'elle crashe, qu'elle disparaisse du réseau, que le disque meure etc.
[^] # Re: container compatible OCI ?
Posté par claudex . Évalué à 3.
C'est pour ça que que les autres nœuds du cluster elasticsearch sont là. Pour pouvoir reprendre si un nœud disparaît.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: container compatible OCI ?
Posté par barmic 🦦 . Évalué à 2.
On utilise la réplication d'es pour ça chez nous.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: container compatible OCI ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
Justement, si tu partages tes disques avec iSER, tu peux faire de la duplication.
Mais j'imagine qu'un truc comme ceph simplifie plein de chose.
"La première sécurité est la liberté"
[^] # Re: container compatible OCI ?
Posté par oau . Évalué à 1.
Ça ce n'est qu'un question d'argent. Si tu es riche tu as 3 machines maîtres k8s et 3 autres monitor pour ceph. N machines pour tes données cephs (OSD) et N autres machines pour k8s (les computes). Si tu es pauvre comme moi tu as 7 machines identiques qui font tout :) et vraiment pour mon usage c'est tout à fait bien.
[^] # Re: container compatible OCI ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
Si tu as 2*N machines, tu as plus de patates et de souplesse, non ? De plus, d'un point de vue flux réseau, cela semble plus efficace d'utiliser les 2*N machines, qu'avoir un flux vers 2x moins de machine. En quoi, cela serait mieux d'avoir 2 types de machines ? (en terme de puissance global de calcul disponible, en terme de débit IO, en terme de taille de disque dispo)
"La première sécurité est la liberté"
[^] # Re: container compatible OCI ?
Posté par oau . Évalué à 1.
En vrai ça dépend de la taille de ton cluster ceph. Si comme moi il est tout petit en stockage (30to) et moins petit en node (7 nodes) effectivement on s'en fout.
Mais sur un cluster plus gros ceph peut être assez violent quand il se reconstruit sur la consommation des ressources. Principalement parce que souvent les gens mettent 3 machines avec 48 disques de 12to. Et quand une machine meurt ou reboot sans le petit noout qui va bien et bien il faut reconstruire beaucoup de données. Si tu as sur les mêmes machine ta prod k8s elle va en souffrir.
[^] # Re: container compatible OCI ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
Dans cet article : https://blog.groupe-sii.com/comparaison-hdfs-glusterfs-ceph/ il compare 3 solutions de stockage distribué, ceph semble assez lent, tu en penses quoi ?
"La première sécurité est la liberté"
[^] # Re: container compatible OCI ?
Posté par oau . Évalué à 1.
depuis 2014 les choses ont bien changé :
petit bench de mon cluster. 7 nodes avec des ssd de 1to et un lien de 2Gbps entre chaque. Sur chaque nodes tourne ceph mais aussi ma prod k8s
montage et formatage de l'image ceph.
rbd map kube/test
mkfs.ext4 /dev/rbd1
mount /dev/rbd1 /mnt/
Un petit dd dedans pour les perf en écriture :
dd if=/dev/zero of=test bs=8192k count=1000 oflag=direct
1000+0 records in
1000+0 records out
8388608000 bytes (8.4 GB, 7.8 GiB) copied, 71.8563 s, 117 MB/s
Les performances de ceph dépendent clairement du réseau. Plus gros sera le réseau plus ca ira vite. Il faut aussi bien faire attention au disques choisis.
[^] # Re: container compatible OCI ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
Je savais que le réseau à bien évolué. Il parait que les SAN baissent d'intéret depuis la sortie d'ethernet en version 100 et 25 gbits sans perte (genre de TCP sur ethernet).
Par contre, sur mon portable de dev, j'ai :
1000+0 enregistrements lus
1000+0 enregistrements écrits
8388608000 octets (8,4 GB, 7,8 GiB) copiés, 15,7548 s, 532 MB/s
Je pourrais aussi dire que la copie linéaire est vraiment le max du max que tu peux avoir. Le nombre d'IO max serait plus intéressant, voir encore mieux pour les DB, le nombre de fsync() par seconde. Les nvme ont d'ailleurs 3 ou 4x plus de fsync/s qu'un hardisk, je m'attendais à beaucoup plus (100 vs 400). Certains SSD pro montent à 3000, et une baie SAN à 23000 (cache en RAM avec batterie).
"La première sécurité est la liberté"
[^] # Re: container compatible OCI ?
Posté par oau . Évalué à 1.
certes. Mais tu compares deux choses qui n'ont rien à voir. Entre un nvme en local et un fs distribué bien sur que tu n'as pas les mêmes performances. Surtout avec un réseau à 2Gbps. C'est pour cette raison que mes pg tourne en local. Mais j'ai retrouvé mes premiers bench sur ma plateforme actuelle avant qu'elle ne passe en production.
Et pgbench me donnait 355 transaction per second sur le ceph
Voici un test sur ma préprop qui est au bureau. Avec 3 noeuds, 6 osd ssd. Mais surtout un réseau de 10Gbps en fibre. Qui fait donc bien 10Gbps.
Voisi le résultat en écriture avec un réplica de 2 ou j'ai un réplica de 3 en prod:
En lecture séquentielle
En lecture aléatoire
On voit bien qu'on est limité par la bande passante du réseau.
Par contre une dernière chose qui peut potentiellement poser problème. Un client qui fait vraiment de très très gros IO sur un cluster peut totalement l'écrouler et pour le moment il n'y a pas vraiment de parade. Si ce n'est de tuer le dit client.
[^] # Re: container compatible OCI ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
Quel outil te génère tes 3 derniers sorties ?
Sinon, plus que la bande passante, ce qui va te gêner se sont le nombre d'IO.
Je trouve étonnant que personne n'a encore fait d'alim de PC avec batterie intégré histoire de garantir l'intégrité d'un "dernier fsync" avant de s'éteindre. Les cartes SAN fonctionnent ainsi, mais cela ne doit pas revenir si chère pour le faire sur un PC classique entier. Ainsi, on pourrait utiliser un fsycn() "réseau" un peu plus relâcher pour augmenter le nombre d'IO, puisque toutes data mis en RAM du serveur serait garanti d'être inscrite sur disque.
Personne n'a encore écrit de scheduler "CFQ" pour le réseau ? Il n'y a rien la dessus dans les cgroup ?
"La première sécurité est la liberté"
[^] # Re: container compatible OCI ?
Posté par oau . Évalué à 2.
oui pardon c'est l'outils de bench rbd qui vient avec ceph.
Pour les cartes raid oui en avoir une avec une batterie est bien sur un plus. Mais dans mon cas une carte raid c'est 57€ HT par mois de plus. C'est à dire 50% de plus par node. Je n'ai pas les moyens et surtout je n'en ai pas le besoin vu mes mes gros I/O sont fait en local directement sur les nvme.
ça discute pas mal sur la ML sur le sujet ces derniers temps. Je dirais que non parce que pour le moment ce n'est pas la piste prise. En gros les monitor discutent avec les osd sur le même canal que les données du cluster. Sur un cluster très chargé avec beaucoup de discussion entre les osd, le message de supervision des monitors peut mettre plusieurs minutes à revenir. Ce qui a pour effet de sortir l'osd du cluster et de lancer une rééquilibrage les données à travers le cluster, donc de le charger encore plus etc.
[^] # Re: container compatible OCI ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
Personne n'offre d'APC par node ? (jamais vue encore) Pourtant, j'avais vu une description des machines Google d'il y a 10 ans, elles contenaient toutes une batterie 12V simple.
"La première sécurité est la liberté"
[^] # Re: container compatible OCI ?
Posté par Psychofox (Mastodon) . Évalué à 2. Dernière modification le 22 mai 2020 à 12:22.
nous on a un cluster ceph mais on ne l'utilise pas pour héberger des volumes kubernetes (ce qui ne veut pas dire que les workloads qui tournent dessus n'y accèdent pas).
On utilise nfs via trident, une interface à netapp, qui crée des shares à la demande.
Il y a d'autres types de baies qui peuvent faire ça via nfs, cifs ,isci…ou si on part dans la virtualisation il y a un outil vmware.
Et après on peut aussi utiliser d'autres systèmes distribués comme openebs, longhorn, linstor, portworx (il existe une version libre), etc…
[^] # Re: container compatible OCI ?
Posté par barmic 🦦 . Évalué à 2.
C'est pas une obligation. Nous on ne déploiement pas nos bases de données sur kubernetes. L'intérêt est très faible pour nous, on a très peu de mouvement sur nos config de db, ce sont des machines spécifiquement taillées pour des bases. Les mettre dans un k8s apporterait quelques trucs, mais pas suffisamment pour qu'on ai envi d'aller se battre avec les volumes et déployer un service comme ceph ou autre. On s'appuie sur les mécanismes natifs des bases pour avoir une haute disponibilité.
Par contre on a un déploiement kubernetes en multimaster ce qui demande un peu de travail en plus de config et de test (ne serais-ce que pour voir comment ça se comporte).
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: container compatible OCI ?
Posté par oau . Évalué à 1.
Effectivement pour mes bases je n’utilise pas ceph. j'utilise stolon que je déploie avec helm et qui gère la réplication de postgres. Postgres qui tourne sur le stockage local qui sera quand même toujours plus rapide que ceph.
Ceph c'est plus pour les disques de elastiksearch, prometheus, pour notre owncloud et comme object storage. Je l'utilise aussi pour les applications que je déploie directement avec helm comme gitlab ou un peu à la mains comme zimbra.
[^] # Re: container compatible OCI ?
Posté par barmic 🦦 . Évalué à 2.
Je ne connais pas les autres ('fin non je connais owncloud et je vois très bien l'intérêt), mais elasticsearch gère sa propre réplication ça n'est pas dommage d'avoir un cluster es sur un cluster ceph ? Ça réplique de la réplication avec des logiques très différentes et des niveaux de garanties très différents.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: container compatible OCI ?
Posté par oau . Évalué à 1.
C'est vrai. Mais je suis très stressé sur la pérennité des données que je reçois. Alors je réplique partout et je backup tout le temps. Mon cluster ceph est d'ailleurs répliqué sur un autre DC au cas ou …
Pour tout dire je reçois mes flux de données sur un serveur. Je transfère les données brutes dans l'object storage de ceph et dans kafka, qui lui a sont propre moyen de réplication et a qui j'ai donné des disques dans ceph. Donc encore répliqué. Et je retiens les données dans kafka indéfiniment.
Ensuite ça passe dans un ETL qui envoie ça dans une base postgres avec 4 réplica. 3 sur des disques locaux géré avec stolon et 1 dans ceph. Celui dans ceph permet de faire des snapshots de postgres pour démarrer une stack de dev avec les même données que dans la prod et alimenté par le kafka. Stack qui est démarré automatiquement quand je pousse une nouvelle branche dans gitlab.
Au final mes dev peuvent avoir en 2/3min une pile applicative complète et à jour sur laquelle développer juste en créant une nouvelle branche.
Et enfin la sortie de l'ETL va aussi dans EKS de même que tout mes logs pour faire un peu de data visualisation avec kibana. Mais sur ce point je ne suis vraiment pas au top.
[^] # Re: container compatible OCI ?
Posté par barmic 🦦 . Évalué à 2.
Effectivement ça a l'air assez complexe. Nous les stockage qu'on veut fiables sont hors k8s et je pousse pour qu'on fasse quelque chose d'assez simple là dessus : quand les données arrivent on les prends et on les envoie dans un cassandra tel quel. Ensuite on en fait les calculs qu'on veut et on peut reconstruire les données calculées à partir de leur sources (je n'aurais pas la prétention de dire que c'est de l'event sourcing parce que ça ne respect pas tous les concepts qui y sont associés, mais ça s'en approche).
Ça c'est cool ! Nous on l'a pas et ce serait difficile à mettre en place (il faut une étape de changement des données pour ne pas faire n'importe quoi d'une part et être respectueux des données utilisateurs d'autre part). On est en mesure de rediriger le flux de prod (avec justement les filtres qui vont bien, vers l'environnement que l'on souhaite).
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: container compatible OCI ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
Avoir un postgresql géré à coté, c'est un peu l'inverse des préconisations microservices, non ? Tu ne peux pas avoir un soft qui se créait sa propre base de donnée et l'utilise (par exemple avec helm).
En tout cas, je note que l'on est loin d'avoir une solution pérenne et performante pour gérer les données persistantes dans k8s.
"La première sécurité est la liberté"
[^] # Re: container compatible OCI ?
Posté par barmic 🦦 . Évalué à 2.
Ça se discute, mais en principe tu ne va pas laisser un service manipuler helm ou même manipuler ton cluster comme ça, ne serais-ce parce que ça pose des problèmes d'un point de vu sécurité. L'idée dans les microservices c'est qu'un service soit seul maitre de sa données. Le fait qu'il crée dynamiquement sa base ne me semble pas être une nécessité et il n'est pas obligé d'avoir sa propre instance de base de données, je ne vois personnellement pas de problème majeure à ce que plusieurs services utilisent des bases de données différentes au sein du même postgres. Bien sûr il y a un niveau de couplage du coup (si tu as des configurations transverse à tes bases postgre elles impactes tout le monde, la charge n'est pas forcément segmentée,…) c'est un choix à arbitrer.
Si tu veux complètement découper, tu va utiliser un controller. C'est un type de container particulier qui est là pour manager des pod. Au déploiement ton service va aller demander une base à ton controller qui va créer la base si nécessaire et te répondre avec les accès qui vont bien. Tu peux même jouer à donner un utilisateur différent à chacun des pods de ton service. Ce qui est particulièrement cool d'un point de vu sécurité. Ça peut te donner des possibilités sympas comme le fait d'utiliser effectivement des instances différentes en prod, mais d'utiliser un seul cluster dans des environnements de dev/test qui sont généralement moins gros.
C'est un gros, vieux et long débat :)
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: container compatible OCI ?
Posté par oau . Évalué à 1.
Je pense qu’on s’est mal compris. Le posgresql en sus qui tourne dans ceph et qui est un replica de la production qui tourne sur des disques en local n’est là que pour avoir la possibilité d’en faire un snapshot.
Mais tout est géré par k8s. Aussi bien le cluster de postgres de prod qui est géré par helm et qui a un Persistent Volume local géré aussi par k8s, et le postgres en sus qui est une image docker que j’ai faite mais qui est géré aussi par k8s (dans un statefulset) et qui a un Persistant Volume dans ceph et enfin les Snaphot de la base dans ceph sont eux aussi géré par k8s via la fonctionnalité de Snapshot de k8s. Je ne fais absolument rien hors de k8s.
Pour clarifier la gestion sur stockage dans k8s. Il y a plusieurs choses.
Le plus simple c’est le stockage éphèmere. Le container écrit sur le disque local du node qui le fait tourner. Quand le container s’arrête tout est perdu.
Ensuite on a la couche stockage persistant. On a d’abord un type storageclass. Dans mon cas j’en ai deux. Une locale et une pour ceph.
Pour la locale je dois créer à la main les lv et les assigner ensuite dans un Persistant Volume (PV), je ne crois pas qu’on puisse encore lui donner un vg et débrouille-toi pour créer les lv.
Pour ceph c’est plus simple. Je crée un Persistant Volume Claim (PVC) qui va créer automatiquement le PV avec la bonne taille.
Avec tout ça il y a un volumesnapshotclass et un volumespnashot qui vont me permettre de créer des snapshot de mes PVC et de les transformer en PV. Ça m’évite de copier 50G de base quand j’ai besoin d’une nouvelle pile pour tester une branche de notre dev.
Là je snapshot mon postgres qui tourne dans ceph et je démarre un nouveau postgres sur le PV créé à partir du snaphost. Merci à postgres d’être capable de se relancer proprement à partir d’un snapshot totalement inconsistant. J’ai vu qu’une commande fsfreeze existait mais pour le moment ça marche.
Donc maintenant j’ai mon pvc.
Si je l’utilise dans un déploiement tous mes pod vont pouvoir y accéder. J’ai donc un volume partagé entre tous mes pods.
Si je l’utilise dans un Statefulset un seul pod pourra utiliser mon pvc et le nom du pod sera fixe.
Je ne suis pas d’accord avec ça. Depuis l’arrivée des Statefulset ce n’est plus le cas.
Si tout à fait. C'est le cas de gitlab, de owncloud par exemple. Tu leur donnes le nom de ta storageclass et ils se débrouillent.
[^] # Re: container compatible OCI ?
Posté par claudex . Évalué à 4.
Ça dépend si tu veux l'installer pour tester, dans ce cas tu as minikube qui te permet de l'installer dans des VM ou sur du baremetal avec docker. Si tu veux faire un truc plus pour de la production, il faut un peut réfléchir à ce que tu veux comme overlay réseau, aux upgrades…
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: container compatible OCI ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
oui je parlais de prod.
"La première sécurité est la liberté"
[^] # Re: container compatible OCI ?
Posté par claudex . Évalué à 3.
Dans ce cas, ça dépend de tes besoins, ça peut être assez simple.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: container compatible OCI ?
Posté par oau . Évalué à 2.
pour tester microk8s est bien plus simple je trouve que minikube qui dans mon souvenir nécessite virtualbox ou kvm
[^] # Re: container compatible OCI ?
Posté par claudex . Évalué à 3.
Non, il peut utiliser docker localement. Mais l'intérêt de l'utilisation de kvm est qu'il s'occupe de tout, pour faire des tests locaux rapide, c'est pratique.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: container compatible OCI ?
Posté par barmic 🦦 . Évalué à 3.
helm c'est l'un des outils qui est là pour générer des configurations k8s et les appliquer. Il permet de faire des templates et de les versionner (et donc de les rollback par exemple). C'est probablement le plus sophistiqué (il gère son propre versionnement, permet d'envoyer ça dans des dépôts,…). Mais il y a un paquet d'alternatives kustomize, pulumi, crossplane, kompose,…
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: container compatible OCI ?
Posté par Psychofox (Mastodon) . Évalué à 4.
Non ce n'est pas si difficile. Il existe en plus des projets comme kubespray (qui en gros est un playbook ansible) ou rancher qui facilitent le déploiement.
Je dirais qu'en tant qu'ingénieur système ce qui est compliqué dans kubernetes ce n'est pas l'ordonnanceur lui-même mais tout ce qu'il y a autour:
- le load balancing
- le réseau inter-clusters
- la gestion des données persistentes
- gérer tout un ecosystème d'applications pour le monitoring, dashboard, ci/cd, registry et chartmuseum privés, éventuellement les db as a service, l'authentification
- la sécurisation via soit via gesion de cluster multiples et/ou de namespaces,les pod security policies, l'open policy agent.
Faut garder en tête que des docker et kubernetes nus gérés comme quand tu suis un tuto pour l'installer sur ton laptop ce sont des failles de sécurité béantes.
[^] # Re: container compatible OCI ?
Posté par CrEv (site web personnel) . Évalué à 2.
C'est un peu mort rkt maintenant… https://github.com/rkt/rkt
gVisor permet aussi de lancer des conteneurs OCI.
Pas totalement. Docker c'est avant tout moby. C'est en partie basé sur containerd mais pas que. Entre autre il existe toujours le format d'image Docker et pas uniquement OCI. Genre quand tu fais un
docker savetu as une image docker, pas oci.# =>[]
Posté par ptit_poulet . Évalué à 6.
C'est développé en Perl ?
Je suis déjà très très loin…
# trivy / analyse d'image
Posté par CrEv (site web personnel) . Évalué à 2.
Trivy permet aussi d'autres choses sympa, comme le fait de scanner les fichers de dépendances ruby, python, etc. Genre les
Gemfile.lockvont être scannés à la recherche des vulnérabilités. L'avantage est que ça fonctionne même si les dépendances ne sont chargées qu'au runtime.Je joue pas mal avec trivy en ce moment, j'aime vraiment bien. C'est petit, rapide, efficace (et open source). C'est aussi facile à poser dans une CI.
Avec des solutions du genre (il y en a aussi d'autres) il n'y a pas vraiment de raisons de s'en passer, et c'est une très bonne aide pour avoir à minima une idées des failles qui sont présentes dans les images.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.