CrEv a écrit 4577 commentaires

J'ai presque le même, juste qu'il est en bluetooth.
J'en suis plutôt satisfait, la frappe est correcte. Généralement j'ai un trackpad à côté (apple parce que j'ai toujours pas trouvé mieux). En gros j'utilise principalement le trackpad et il m'arrive de temps en temps d'utiliser le trackpoint du clavier, genre pour du scroll.

Le seul truc que je regrette c'est le fn/ctrl inversé par rapport à mes autres claviers (apple aussi).

Mais globalement c'est un bon clavier.

Et si on regardait par l'autre côté.
Mais pour ça il faut commencer par se poser la question suivante : à quoi servent ces données ? Note : je parle des données type crash report, stats d'utilisations des outils.

L'idée derrière ce n'est pas de traquer les utilisateurs (tout le monde s'en fout), c'est de comprendre ce qu'ils font, comment ils utilisent les outils, quelles actions par contre sont peu/pas utilisées et de pouvoir s'en servir pour

• fournir de meilleurs outils en améliorant ce qui est utilisé
• supprimer ce qui semble inutile et coûte (en maintenance, complexité, etc)
• savoir qu'une fonctionnalité très intéressante est trop peu utilisée donc la mettre plus en avant
• …

Alors oui dans un monde binaire c'est le Mal, dans les fait c'est un des outils qui permet de construire de meilleurs logiciels.

certains conteneurs contiennent des logiciels malveillants ou des mineurs de cryptomonnaies

Oui, c'est un cas assez fréquent malheureusement :-( Lorsque nous en sommes avertis nous les supprimons.

les risques potentiels à utiliser des dépôts tiers de manière générale

Oui, globalement il n'y a pas de solution miracle sur ce point. La seule chose c'est de privilégier les dépôts principaux, ou les images vérifiées dans le cadre de Docker. Tout comme on installerait que depuis les dépots debian officiels par exemple.

les conteneurs sont testé en contexte

Oui, j'ai vu cette phrase :

Each image was executed in an isolated controlled environment

Mais je ne suis pas bien certains de savoir ce que ça veut dire. Beaucoup d'images ne peuvent pas être exécutées simplement (je veux dire un simple docker run sans paramètres, sans variables d'environnement, sans dépendances, etc).

mouai, la rédaction est au mieux trompeuse.

D’après l’analyse de sécurité récente des 4 millions d'images de conteneurs hébergées sur le référentiel Docker Hub

Il y a beaucoup plus que 4 millions d'images sur le Hub. Sur les derniers chiffre public que j'ai, il y en a 150 millions.

Après oui une grosse part du problème est que beaucoup de monde a poussé des images, puis ne les maintient pas (ou ne les supprime pas). Donc à un moment donné on découvre des vulnérabilités 🤷‍♂️

c'est justement pour ça qu'on a entre autre intégré un scanner de vulnérabilités dans Docker Hub : à chaque push on peut avoir un scan de l'image et connaitre les vulnérabilités présentes. https://docs.docker.com/docker-hub/vulnerability-scanning/
Il est aussi possible de scanner en local : https://docs.docker.com/engine/scan/

---

note : je bosse chez Docker, j'ai développé la feature de scan du Docker Hub.

Rust est le seul qui prend de l'envol aujourd'hui

C'est surtout que Go a déjà pris son envol il y a plusieurs années :-)

Sinon du code en Ada ça existe pas mal (aviation, ferroviaire). C'est moins tendance et plus sur une niche mais c'est pas pour autant que c'est mort.

un seul CV, pas de lettre de motivation. Tout ça on oublie. Un mail suffit, là il sera évidemment spécifique. Et le reste se joue en entretien.

Le but du CV (et de ce qui l'accompagne, que ce soit une lettre formelle ou un mail) c'est justement d'accéder à l'entretien.
Un CV trop général/passe partout peut tout simplement faire louper l'accès à l'entretien.
Après en effet ça dépend aussi du ratio entre nombre de poste à pourvoir et nombre de candidats, quand tu commences à avoir des dizaines ou centaines de candidats pour un nombre de postes qui se compte sur les doigts d'une seule main c'est chaud.

Comment on peut coder avec le clavier du mac ??

Avec un clavier qwerty tout simplement ? ;-)

C'est pas chiant au jour le jour ?

Non.
Je n'utilise simplement quasiment jamais les menus. C'est un truc que j'aime bien dans la majorité des apps que j'utilise, elles sont utilisables sans menu. Donc le fait qu'il soit en haut est bien car ça me supprime une ligne inutile au niveau de l'appli.

Et pour le reste, il y a la touchbar :-)

Et du coup, le bouton d'aggrandissement vert il fait quoi quand on appuie pas sur la touche Option ?

Par défaut le bouton passe en plein écran.

Le plein écran est tellement mieux géré en collaboration avec les bureaux virtuels sous mac que sous linux : tu peux avoir plusieurs applications en plein écran. Un plein écran est géré comme un bureau virtuel, il est donc possible de les réordonner. Il est aussi facile de passer d'une app en plein écran à une app qui ne l'est pas et y revenir, c'est exactement comme changer de bureau.

Franchement c'est le genre de fonctionnalité que j'utilise constamment et je pourrais difficilement m'en passer (je veux dire sauf si on me proposait une meilleure fonctionnalité, mais j'ai pas vu sur ce point)

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.

Trivy permet aussi d'autres choses sympa, comme le fait de scanner les fichers de dépendances ruby, python, etc. Genre les Gemfile.lock vont ê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.

rkt

C'est un peu mort rkt maintenant… https://github.com/rkt/rkt

gVisor permet aussi de lancer des conteneurs OCI.

Note qu'il me semble que docker n'est maintenant plus qu'un emballage pour containerd

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 save tu as une image docker, pas oci.

est-ce que les médecins et pharmaciens qui témoignent en faveur de l'euthanasie confondent avec les soins palliatifs ?

Cet article en tout cas oui.

https://www.liberation.fr/checknews/2020/03/29/acces-a-la-reanimation-des-consignes-officielles-ont-elles-ete-donnees-pour-les-residents-d-ehpad_1783370 est déjà beaucoup plus intéressant.

Mais franchement, les raccourcis sont grossiers. Passer de "patients pour lesquels l'hospitalisation ne serait pas bénéfique" à "on euthanasie les petits vieux" c'est ridicule.
La question de la mort et de l'acharnement thérapeutique (on parle de réa et de coma) est déjà (sans parler de cette épidémie) une préoccupation des EHPAD.

On en est définitivement plus à chercher à savoir qui est malade ou pas

Oui, c'était peut-être mal tourné mais ma remarque était juste sur le fonctionnement de ce type de masque pour pouvoir le comparer aux FFP2 (tout le monde voit le terme mais personne ne sait à quoi ça sert).

Donc oui, on évite de se faire contaminer

Justement, un masque type chirurgical n'est pas une protection pour celui qui le porte, tu peux te faire contaminer. Il est une protection pour les autres.

Sérieusement, je but étant de protéger les autres de ses postillons

Ben non.
Ça c'est le but pour la personne infectée, limiter les projections.
Pour la personne saine en face c'est de ne pas pouvoir l'inhaler, et ça c'est une autre histoire.

je ne vois pas pourquoi on se casse la tête à acheter ou à faire des masques, dans la mesure où une simple écharpe peut faire aussi bien.

Je me demande pourquoi personne n'y a pensé avant 🤔

Il y a pas mal de trucs dans tous les sens autours des masques. Jusqu'à "plus simple une écharpe et ça marche" (spoiler, faux).

masques de type chirurgical

C'est l'image que vous avez le plus des masques car c'est ceux qu'on voit souvent.
C'est ce qu'on appel un masque anti projection. Il n'est utile qu'au malade (bon ici on peut supposer que beaucoup soient à risque, y compris sans le savoir). Mais ça reste limité.
Ce genre de masque dès qu'il commence à être mouillé/souillé on le jette, si on le baisse on le change, si on l'enlève on le remet pas, etc.

masques de type FFP2

C'est un masque de protection respiratoire individuelle.
Le but ici n'est pas de bloquer les projections (même si c'est évidemment aussi le cas) mais il protège surtout contre le risque d'inhalation. C'est pourquoi il est plus couvrant et possède un filtre.
Etant donné que le virus peut rester en l'air un certains temps, sans un masque du genre si vous êtes face à une personne infectée vous risquez de l'être juste en respirant. Dans ce sens une écharpe ou autre dispositif plus limité risque de ne juste servir à rien.
Un tel masque a une durée de vie limitée. Généralement 3 heures, 4 max.

Les types de masques : https://solidarites-sante.gouv.fr/IMG/pdf/Fiche_Masques.pdf

Maintenant sur la fabrication des masques (vu la véhémence de certains commentaires). Ces masques en tissus (mais avec une couche filtrante au milieu, c'est ça qui est important pas juste le tissu) sont actuellement fabriqués par les personnels (entre autre sur demande des directions) et utilisés dans les hôpitaux.

Pour ce qui est de l'usage, pour comprendre un peu plus :

Ce modèle n’est pas destiné au personnel qui prend en charge des patients atteints du Covid-19, mais à tous les autres, infirmiers et aides-soignants, qui travaillent en milieu hospitalier et dispensent des soins.
-- source

Ça dépend ce que tu appelles « conteneur ». Si pour toi conteneur ≡ docker, alors oui, ce n’est pas le concept. Mais si ce qu’on appelle conteneur, c’est juste une manière de cloisonner les services

J'utilise ce que la majeur partie des gens appellent conteneur aujourd'hui, c'est à dire du Docker, podman ou autres solutions OCI compliant.
Après on peut sortir d'autres définitions, qui sont aussi valables, mais à mon avis mon proches de ce qui est entendu.

Par contre je veux pouvoir facilement le ou la sauvegarder et transférer vers un autre serveur.

Le principe des conteneurs c'est d'être immuable.
Le code et les resources sont dans une image. Tu lance une instance, tu la stop, aucune donnée n'aura été sauvegardée dans l'image. Donc au prochain lancement tu repars de zéro.
Donc le "je sauvegarde et je transfert" bof. Après tu peux évidemment utiliser des volumes, mais bon si c'est pour avoir une image -> une instance de conteneur -> un volume persistant je suis pas certains de voir la valeur.

Mon avis comme ça c'est que ce que tu cherches à faire ne rentre pas vraiment dans le concept du conteneur.

Si par exemple je veux un conteneur "serveur de mail" qui contient un postfix, dovecot et antispam,

Ça existe, c'est une VM :-D
Dans laquelle chaque processus pourra être un conteneur :-)

La question ici c'est pourquoi veux-tu un conteneur "serveur de mail" ? Quel est le but, quel problème tu cherches à résoudre ?
Suivant les problèmes, il existe différentes solutions :

• vm (avec des scripts qui te gères tes services, du terraform, ansible ou autre suivant les besoins)
• docker-compose
• docker app (ou autre solution compatible CNAB)
• un orchestrateur

Tu peux mettre tout ça dans un seul conteneur (Docker ou non c'est pas la question) mais je pense pas que ce soit suivre de bonnes pratiques ni que ça corresponde à un problème que les conteneurs cherchent à résoudre.

les devops existent … c'est pas une légende urbaine :)

Et c'est donc quoi un devops ?

mais bon tant que les devs et autres grosses têtes n'auront pas été upgradé en … bon sens, nous aurons (les sysadmins) du travail c'est sur.

C'est marrant on peut écrire exactement l'inverse.

Pour être plus précis : existe t il quelque chose qui te permette de voir si un container devient fou et bouffe plus de CPU que la normale ou génére des I/O de manière exagérées …

Ça reste mega vague.
Si la question est de savoir s'il y a de quoi faire du monitoring de conteneurs, avoir de l'alerting, etc, la réponse est oui.
Sachant que Docker reste, contrairement à une VM, juste de l'isolation autour de processus.
Et après il existe plein d'outils si tu veux inspecter ce qui se passe, dans le genre puissant (mais encore une fois ça reste vague) tu peux jouer avec sysdig par exemple.

Pour exécuter des containeurs, ils y a containerd, CRI-O, rkt (bon celui là est laissé de côté au profit des deux précédent), etc.

C'est plus que ça pour rkt, le projet est mort et archivé : https://github.com/rkt/rkt/issues/4024

• un assemblage de référence, appelé Moby Origin, qui est la base logicielle ouverte pour Docker, ainsi que des exemples de systèmes de conteneurs utilisant différents composants de la bibliothèque Moby ou d'autres projets.

Je sais pas exactement ce qu'est Origin, j'en trouve référence dans l'annonce initiale de moby mais c'est tout. Après c'est juste une histoire de terme, docker le daemon qui tourne c'est bien directement basé sur moby.

Mais dans un contexte de PROD et d'exploitation :

Des prods sous Docker c'est pas ce qui manque.

quand il y a un soucis de performance comment cela se passe ?

C'est quoi un soucis de performance ?

En fait c'est hyper mega vague qu'il est pas vraiment possible de répondre quoi que ce soit.

Et bon c'est pas parce que tu as des conteneurs que tu n'as plus d'ops qui gèrent ta plateforme. Donc oui si tout le monde se refile la patate chaude aujourd'hui, tu peux remplacer tes vms par des conteneurs ou par des binaires que ça ne change absolument rien au problème.

De mémoire, l’entrypoint est aussi exécuté quand tu fais un docker exec (ce qui t’empêche de rentrer dans ton container pour le débuger), non ?

À priori non.

Voici un Dockerfile avec un entrypoint qui est une boucle infinie :

FROM alpine:3.11

ENTRYPOINT while :; do sleep 1; done

docker build -t loop .
CID=`docker run --rm -d loop`
docker exec -it $CID sh
/ #

1. build du conteneur
2. lancer le conteneur et récupérer son ID
3. exec dans le conteneur en lançant sh

Si l'entrypoint n'était pas overridé on ne pourrait pas.

Il est utile dans tout les cas ou tu veux pouvoir envoyer un signal à ton application alors que celui-ci ne le « trap » pas explicitement et tous les cas où il peut y avoir des sous-processus. Presque tout le temps en fait.

Je dois pas faire assez de java en conteneur alors, car je ne le vois (quasiment) jamais.

Si l'application ne gère pas les signaux c'est un problème, mais ça devrait être corrigé dans l'application et non par l'adjonction d'un init.

entrypoint/cmd ça se défend, ça dépend surtout de l'usage. Ici avec l'entrypooint ça veut dire que tout ce que tu rajoutes au docker run sera envoyé dans cmd et entrypoint + cmd est executé.
C'est parfois super pratique.

Par contre dumb-init je vois pas du tout l'intérêt voir je marquerais ça comme une mauvaise pratique.
A partir du moment où on commence à rentrer des notions d'init dans les conteneurs faut se poser des questions sur ce qu'on fait et pourquoi. Il peut y avoir des cas où c'est nécessaire, mais plutôt rare et à éviter.

Quelques points qui peuvent être améliorés :

• le mkdir est inutile, WORKDIR le fait déjà
• COPY est à préférer par rapport à ADD qui fait plein d'autres trucs. Voir https://github.com/hadolint/hadolint/wiki/DL3020 par exemple
• on peut remplacer les targets de COPY par . dans le workdir
• c'est plus personnel, mais j'aime bien l'entrypoint (et cmd) en tableau de string
• je ne taggerais pas la dernière image, pour pouvoir faire un docker build sans avoir besoin de lui passer la target

FROM maven:3.6-jdk-11 as build
WORKDIR /jb3

COPY pom.xml .
COPY src .

RUN echo "spring.data.mongodb.host=mongodb" >> /jb3/src/main/resources/config/application.properties

RUN mvn package

FROM adoptopenjdk/openjdk11:alpine-slim
WORKDIR /code

COPY --from=build /jb3/target/jb3-1.2-SNAPSHOT.jar .

EXPOSE 8080

ENTRYPOINT [ "java", "-jar", "jb3-1.2-SNAPSHOT.jar" ]

Sinon les multistage builds c'est bon mangez-en !