{"id":97254,"date":"2020-10-17T02:42:32","date_gmt":"2020-10-17T00:42:32","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/prosti-openshift-my-nedostatochno-czenili-tebya-i-prinimali-kak-dolzhnoe"},"modified":"2020-10-17T02:42:32","modified_gmt":"2020-10-17T00:42:32","slug":"prosti-openshift-my-nedostatochno-czenili-tebya-i-prinimali-kak-dolzhnoe","status":"publish","type":"post","link":"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/prosti-openshift-my-nedostatochno-czenili-tebya-i-prinimali-kak-dolzhnoe","title":{"rendered":"D\u00e9sol\u00e9, OpenShift, nous ne t'avons pas assez appr\u00e9ci\u00e9 et nous t'avons pris pour acquis","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Cet article a \u00e9t\u00e9 r\u00e9dig\u00e9 car nos employ\u00e9s ont eu de nombreuses conversations avec des clients sur le d\u00e9veloppement d'applications sur Kubernetes et les sp\u00e9cificit\u00e9s de ce type de d\u00e9veloppement sur OpenShift.<\/p>\n

\"D\u00e9sol\u00e9,
\n
\nNous commen\u00e7ons g\u00e9n\u00e9ralement par le principe que Kubernetes est simplement Kubernetes, tandis qu'OpenShift est une plateforme Kubernetes, comme Microsoft AKS ou Amazon EKS. Chacune de ces plateformes a ses avantages, orient\u00e9s vers un public cible sp\u00e9cifique. Apr\u00e8s cela, la discussion \u00e9volue vers la comparaison des forces et des faiblesses de ces plateformes.
\n<\/a><\/noindex>
\nEn gros, nous envisagions d'\u00e9crire cet article avec une conclusion du type \u00ab \u00c9coutez, peu importe o\u00f9 ex\u00e9cuter le code, sur OpenShift ou sur AKS, sur EKS, sur un Kubernetes personnalis\u00e9, peu importe, c'est du Kubernetes \u00bb (pour abr\u00e9ger, appelons-le KUK)<\/i> \u2013 c'est vraiment simple, que ce soit l'un ou l'autre.<\/p>\n

Nous avions ensuite pr\u00e9vu de prendre un simple \u00ab Hello World \u00bb et d'utiliser cet exemple pour montrer ce qui est commun et ce qui diff\u00e9rencie KUK de la Red Hat OpenShift Container Platform (ci-apr\u00e8s OCP ou simplement OpenShift).<\/p>\n

Cependant, en r\u00e9digeant cet article, nous avons r\u00e9alis\u00e9 que nous \u00e9tions tellement habitu\u00e9s \u00e0 utiliser OpenShift que nous ne r\u00e9alisions pas \u00e0 quel point il avait grandi et s'\u00e9tait transform\u00e9 en une plateforme impressionnante, beaucoup plus qu'un simple distribution de Kubernetes. Nous avons tendance \u00e0 prendre pour acquis la maturit\u00e9 et la simplicit\u00e9 d'OpenShift, oubliant sa magnificence.<\/p>\n

Il est donc temps de se racheter en passant \u00e0 l'action, et maintenant nous allons comparer pas \u00e0 pas le d\u00e9ploiement de notre \u00ab Hello World \u00bb sur KUK et sur OpenShift, et nous allons le faire de mani\u00e8re aussi objective que possible (\u00e0 part peut-\u00eatre des expressions parfois subjectives). Si vous \u00eates int\u00e9ress\u00e9 par une opinion purement subjective \u00e0 ce sujet, vous pouvez la lire ici (EN)<\/a><\/noindex>. Cet article se concentrera sur les faits et uniquement sur les faits.<\/p>\n

Clusters<\/h3>\n

\nPour notre \u00ab Hello World \u00bb, nous avons besoin de clusters. D'abord, disons non \u00e0 tous les clouds publics pour \u00e9viter de payer pour les serveurs, les registries, les r\u00e9seaux, le transfert de donn\u00e9es, etc. Par cons\u00e9quent, nous choisissons un simple cluster \u00e0 n\u0153ud unique sur Minikube<\/a><\/noindex> (pour KUK) et Code Ready Containers<\/a><\/noindex> (pour le cluster OpenShift). Ces deux options sont en r\u00e9alit\u00e9 tr\u00e8s simples \u00e0 installer, mais n\u00e9cessiteront pas mal de ressources sur votre ordinateur portable.<\/p>\n

\"D\u00e9sol\u00e9,<\/p>\n

Compilation sur KUK<\/h3>\n

\nAlors, c'est parti.<\/p>\n

\u00c9tape 1 \u2013 construisons notre image de conteneur<\/h4>\n

\nJe commencerai par d\u00e9ployer notre \u00ab Hello World \u00bb sur minikube. Pour cela, nous aurons besoin de :<\/p>\n

    \n
  1. 1. Docker install\u00e9.<\/li>\n
  2. 2. Git install\u00e9.<\/li>\n
  3. 3. Maven install\u00e9 (en fait, ce projet utilise le binaire mvnw, donc cela peut se faire sans lui).<\/li>\n
  4. 4. Le code source lui-m\u00eame, c'est-\u00e0-dire le clonage du d\u00e9p\u00f4t github.com\/gcolman\/quarkus-hello-world.git<\/a><\/noindex><\/li>\n<\/ol>\n

    \nLa premi\u00e8re chose \u00e0 faire est de cr\u00e9er un projet Quarkus. Ne vous inqui\u00e9tez pas si vous n'avez jamais travaill\u00e9 avec le site Quarkus.io \u2013 c'est facile. Il suffit de choisir les composants que vous souhaitez utiliser dans le projet (RestEasy, Hibernate, Amazon SQS, Camel, etc.), puis Quarkus configure d\u00e9j\u00e0 tout cela automatiquement sans votre intervention, en cr\u00e9ant un arch\u00e9type Maven et en le publiant sur GitHub. C'est-\u00e0-dire qu'il suffit de cliquer une seule fois \u2013 et c'est pr\u00eat. C'est pourquoi nous aimons Quarkus.<\/p>\n

    \"D\u00e9sol\u00e9,<\/p>\n

    La mani\u00e8re la plus simple de builder notre 'Hello World' en tant qu'image de conteneur est d'utiliser les extensions quarkus-maven pour Docker, qui s'occupent de tout le travail n\u00e9cessaire. Avec l'arriv\u00e9e de Quarkus, cela est devenu vraiment facile : ajoutez l'extension container-image-docker et vous pouvez cr\u00e9er des images avec des commandes Maven.<\/p>\n

    .\/mvnw quarkus:add-extension -Dextensions=\"container-image-docker\"\n<\/code><\/pre>\n
    \nEt enfin, nous construisons notre image en utilisant Maven. En cons\u00e9quence, notre code source se transforme en une image de conteneur pr\u00eate \u00e0 \u00eatre ex\u00e9cut\u00e9e dans un environnement de conteneurs.<\/p>\n
    \"D\u00e9sol\u00e9,<\/p>\n
    .\/mvnw -X clean package -Dquarkus.container-image.build=true\n<\/code><\/pre>\n
    \nVoil\u00e0, c'est tout, maintenant vous pouvez ex\u00e9cuter le conteneur avec la commande docker run, en mappant notre service sur le port 8080 pour y acc\u00e9der.<\/p>\n
    docker run -i --rm -p 8080:8080 gcolman\/quarkus-hello-world\n<\/code><\/pre>\n
    \"D\u00e9sol\u00e9,<\/p>\n
    Une fois l'instance du conteneur d\u00e9marr\u00e9e, il suffit de v\u00e9rifier avec la commande curl que notre service fonctionne :<\/p>\n
    \"D\u00e9sol\u00e9,<\/p>\n
    Donc, tout fonctionne, et c'\u00e9tait vraiment facile.<\/p>\n
    \u00c9tape 2 \u2013 envoyons notre conteneur dans le d\u00e9p\u00f4t d'images de conteneur.<\/h4>\n
    \nPour l'instant, l'image que nous avons cr\u00e9\u00e9e est stock\u00e9e localement dans notre registre de conteneurs local. Si nous voulons utiliser cette image dans notre environnement K8S, nous devons la placer dans un autre d\u00e9p\u00f4t. Kubernetes ne dispose pas de telles fonctionnalit\u00e9s, nous allons donc utiliser Docker Hub. Parce que, d'une part, c'est gratuit, et d'autre part, (presque) tout le monde le fait.<\/p>\n
    C'est aussi tr\u00e8s simple, il vous faut juste un compte sur Docker Hub.<\/p>\n
    Alors, nous configurons Docker Hub et envoyons notre image l\u00e0-bas.<\/p>\n
    \"D\u00e9sol\u00e9,<\/p>\n
    \u00c9tape 3 \u2013 d\u00e9marrons Kubernetes.<\/h4>\n
    \nIl existe de nombreuses fa\u00e7ons de configurer Kubernetes pour ex\u00e9cuter notre 'Hello World', mais nous allons utiliser la plus simple, car c'est notre nature...<\/p>\n
    Pour commencer, lan\u00e7ons le cluster minikube :<\/p>\n
    minikube start\n<\/code><\/pre>\n
    <\/p>\n
    \u00c9tape 4 \u2013 d\u00e9ployons notre image de conteneur<\/h4>\n
    \nNous devons maintenant transformer notre code et notre image de conteneur en configurations Kubernetes. En d'autres termes, nous avons besoin d'une d\u00e9finition de pod et de d\u00e9ploiement qui pointe vers notre image sur Docker Hub. L'un des moyens les plus simples de le faire est d'ex\u00e9cuter la commande create deployment en sp\u00e9cifiant notre image :<\/p>\n
    \"D\u00e9sol\u00e9,<\/p>\n
    kubectl create deployment hello-quarkus --image=gcolman\/quarkus-hello-world:1.0.0-SNAPSHOT\n<\/code><\/pre>\n
    \nAvec cette commande, nous avons demand\u00e9 \u00e0 notre K8S de cr\u00e9er une configuration de d\u00e9ploiement, qui doit contenir la sp\u00e9cification du pod pour notre image de conteneur. Cette commande appliquera \u00e9galement cette configuration \u00e0 notre cluster Minikube et cr\u00e9era un d\u00e9ploiement qui t\u00e9l\u00e9chargera notre image de conteneur et lancera le pod dans le cluster.<\/p>\n
    \u00c9tape 5 \u2013 ouvrons l'acc\u00e8s \u00e0 notre service<\/h4>\n
    \nMaintenant que nous avons d\u00e9ploy\u00e9 notre image de conteneur, il est temps de penser \u00e0 la configuration de l'acc\u00e8s externe \u00e0 ce service Restful, qui est en fait programm\u00e9 dans notre code.<\/p>\n
    Il existe de nombreuses fa\u00e7ons de proc\u00e9der. Par exemple, nous pouvons utiliser la commande expose pour cr\u00e9er automatiquement les composants Kubernetes correspondants, tels que les services et les points de terminaison. C'est exactement ce que nous allons faire en ex\u00e9cutant la commande expose pour notre objet de d\u00e9ploiement :<\/p>\n
    kubectl expose deployment hello-quarkus --type=NodePort --port=8080\n<\/code><\/pre>\n
    \nPrenons un moment pour examiner l'option \u00ab --type \u00bb de la commande expose.<\/p>\n
    Lorsque nous faisons l'expose et cr\u00e9ons les composants n\u00e9cessaires pour faire fonctionner notre service, nous devons, entre autres, nous assurer que l'ext\u00e9rieur peut se connecter au service hello-quarkus, qui se trouve dans notre r\u00e9seau d\u00e9fini par logiciel. Et le param\u00e8tre type<\/b> nous permet de cr\u00e9er et de connecter des \u00e9l\u00e9ments comme des \u00e9quilibreurs de charge pour diriger le trafic vers ce r\u00e9seau.<\/p>\n
    Par exemple, en sp\u00e9cifiant --type=LoadBalancer<\/b>, nous initialisons automatiquement un \u00e9quilibreur de charge dans le cloud public pour se connecter \u00e0 notre cluster Kubernetes. C'est \u00e9videmment formidable, mais il faut comprendre qu'une telle configuration sera strictement li\u00e9e \u00e0 un cloud public particulier et qu'il sera plus difficile de la transf\u00e9rer entre les instances Kubernetes dans diff\u00e9rents environnements.<\/p>\n
    Dans notre exemple --type=NodePort<\/b>, c\u2019est-\u00e0-dire que l'acc\u00e8s \u00e0 notre service se fait via l'adresse IP du n\u0153ud et le num\u00e9ro de port. Cette option permet de ne pas utiliser de clouds publics, mais n\u00e9cessite quelques \u00e9tapes suppl\u00e9mentaires. Tout d'abord, nous avons besoin de notre propre r\u00e9partiteur de charge, donc nous allons d\u00e9ployer un r\u00e9partiteur de charge NGINX dans notre cluster.<\/p>\n
    \u00c9tape 6 \u2013 Installer le r\u00e9partiteur de charge<\/h4>\n
    \nMinikube dispose de plusieurs fonctionnalit\u00e9s de plateforme facilitant la cr\u00e9ation des composants n\u00e9cessaires pour l'acc\u00e8s externe, comme les contr\u00f4leurs d'ingress. Minikube est livr\u00e9 avec un contr\u00f4leur d'ingress Nginx, et il ne nous reste plus qu'\u00e0 l'activer et le configurer.<\/p>\n
    minikube addons enable ingress\n<\/code><\/pre>\n
    \nMaintenant, avec une seule commande, nous allons cr\u00e9er un contr\u00f4leur d'ingress Ngnix qui fonctionnera \u00e0 l'int\u00e9rieur de notre cluster minikube :<\/p>\n
    ingress-nginx-controller-69ccf5d9d8-j5gs9 1\/1 En cours d\u2019ex\u00e9cution 1 33m\n<\/code><\/pre>\n
    <\/p>\n
    \u00c9tape 7 \u2013 Configurer l'ingress<\/h4>\n
    \nNous devons maintenant configurer le contr\u00f4leur d'ingress Nginx afin qu'il g\u00e8re les requ\u00eates hello-quarkus.<\/p>\n
    \"D\u00e9sol\u00e9,<\/p>\n
    \"D\u00e9sol\u00e9,<\/p>\n
    Et enfin, nous devons appliquer cette configuration.<\/p>\n
    \"D\u00e9sol\u00e9,<\/p>\n
    kubectl apply -f ingress.yml\n<\/code><\/pre>\n
    \"D\u00e9sol\u00e9,<\/p>\n
    Puisque nous faisons tout cela sur notre ordinateur, nous ajoutons simplement l'adresse IP de notre n\u0153ud dans le fichier \/etc\/hosts, afin de diriger les requ\u00eates http vers notre minikube sur le r\u00e9partiteur de charge NGINX.<\/p>\n
    192.168.99.100 hello-quarkus.info\n<\/code><\/pre>\n
    \nVoil\u00e0, maintenant notre service minikube est accessible de l'ext\u00e9rieur via le contr\u00f4leur d'ingress Nginx.<\/p>\n
    \"D\u00e9sol\u00e9,<\/p>\n
    Alors, c'\u00e9tait facile, n'est-ce pas ? Ou pas vraiment ?<\/h3>\n
    \"D\u00e9sol\u00e9,<\/p>\n
    D\u00e9ploiement sur OpenShift (Code Ready Containers)<\/h3>\n
    \nVoyons maintenant comment cela se passe sur la plateforme de conteneurs Red Hat OpenShift (OCP).<\/p>\n
    Comme pour minikube, nous choisissons le sch\u00e9ma d'un cluster \u00e0 n\u0153ud unique OpenShift sous forme de Code Ready Containers (CRC). Cela s'appelait auparavant minishift et \u00e9tait bas\u00e9 sur le projet OpenShift Origin, et maintenant c\u2019est CRC et cela repose sur la plateforme de conteneurs OpenShift de Red Hat.<\/p>\n
    Ici, nous ne pouvons pas nous emp\u00eacher de dire : \u00ab OpenShift est formidable ! \u00bb<\/p>\n
    Au d\u00e9part, nous pensions \u00e9crire que le d\u00e9veloppement sur OpenShift ne diff\u00e9rait pas de celui sur Kubernetes. Et en fait, c\u2019est vrai. Mais en r\u00e9digeant cet article, nous avons r\u00e9alis\u00e9 combien de mouvements suppl\u00e9mentaires \u00e9taient n\u00e9cessaires quand on n\u2019a pas OpenShift, ce qui prouve encore une fois que c'est formidable. Nous aimons quand les choses sont simples, et la facilit\u00e9 avec laquelle notre exemple se d\u00e9ploie et s'ex\u00e9cute sur OpenShift par rapport \u00e0 minikube nous a incit\u00e9s \u00e0 \u00e9crire cet article.<\/p>\n
    Passons en revue le processus et voyons ce que nous devrons faire.<\/p>\n
    Ainsi, dans l'exemple avec minikube, nous commencions avec Docker\u2026 Attendez, nous n'avons plus besoin que Docker soit install\u00e9 sur la machine.<\/p>\n
    Et nous n'avons pas besoin de git local.
    \nEt nous n'avons pas besoin de Maven.
    \nEt il n'est pas n\u00e9cessaire de cr\u00e9er manuellement une image de conteneur.
    \nEt il n'est pas n\u00e9cessaire de chercher un d\u00e9p\u00f4t d'images de conteneurs.
    \nEt il n'est pas n\u00e9cessaire d'installer un contr\u00f4leur d'ingress.
    \nEt il n'est pas non plus n\u00e9cessaire de configurer l'ingress.<\/b><\/p>\n
    Vous comprenez, n'est-ce pas ? Pour d\u00e9ployer et ex\u00e9cuter notre application sur OpenShift, rien de ce qui pr\u00e9c\u00e8de n'est n\u00e9cessaire. Et le processus ressemble \u00e0 ceci.<\/p>\n
    \u00c9tape 1 \u2013 D\u00e9marrez votre cluster OpenShift<\/h4>\n
    \nNous utilisons Code Ready Containers de Red Hat, qui est en fait le m\u00eame que Minikube, mais avec un cluster OpenShift \u00e0 n\u0153ud unique complet.<\/p>\n
    crc start\n<\/code><\/pre>\n
    <\/p>\n
    \u00c9tape 2 \u2013 Construisez et d\u00e9ployez l'application dans le cluster OpenShift<\/h4>\n
    \nC'est \u00e0 cette \u00e9tape que la simplicit\u00e9 et la commodit\u00e9 d'OpenShift brillent de tous leurs feux. Comme dans toutes les distributions Kubernetes, nous avons de nombreuses fa\u00e7ons de d\u00e9ployer une application dans le cluster. Et, comme dans le cas de K8s, nous choisissons d\u00e9lib\u00e9r\u00e9ment la m\u00e9thode la plus simple.<\/p>\n
    OpenShift a toujours \u00e9t\u00e9 con\u00e7u comme une plateforme pour cr\u00e9er et ex\u00e9cuter des applications conteneuris\u00e9es. La construction de conteneurs a toujours \u00e9t\u00e9 une partie int\u00e9grante de cette plateforme, c'est pourquoi il existe de nombreuses ressources Kubernetes suppl\u00e9mentaires pour les t\u00e2ches correspondantes.<\/p>\n
    Nous allons utiliser le processus Source 2 Image (S2I) d'OpenShift, qui offre plusieurs m\u00e9thodes pour prendre notre source (code ou fichiers binaires) et la transformer en une image de conteneur ex\u00e9cut\u00e9e dans un cluster OpenShift.<\/p>\n
    Pour cela, nous aurons besoin de deux choses :<\/p>\n