Différences entre gitlab.com (SaaS) et GitLab autogéré (Self-managed)

Au cours des deux dernières années, de nombreuses personnes nous ont demandé quelles étaient les différences entre GitLab Self-managed (votre propre serveur privé)
et gitlab.com (la solution SaaS de GitLab).
Beaucoup sont confus quant à l’utilisation de GitLab dans le cloud,
C’est pourquoi j’ai décidé de publier un article complet et actualisé sur le sujet, basé sur les connaissances accumulées de notre entreprise, qui inclura tous les aspects et considérations pertinents au sujet.

GitLab Self-managed vs gitlab.com

J’ai divisé la réponse en une réponse courte et une réponse longue.

Les différences – en bref :

Dans GitLab Self-managed, vous aurez un contrôle total sur le serveur lui-même et sur l’environnement, avec tout ce que cela implique :
Sécurité, confidentialité, données, temps d’arrêt planifié, performances, latence.
Le serveur est sous votre responsabilité et vous aurez un accès root, vous aurez donc un contrôle total sur celui-ci.

En revanche – sur gitlab.com, vous obtiendrez bien sûr une instance privée, mais il est toujours important de se rappeler que vous partagez en fait le serveur avec d’autres (d’autres sociétés ou des particuliers) que vous ne connaissez pas. Il s’agit en fait d’une solution multi-locataire, ce qui affecte les considérations de performances, la sécurité des informations, la confidentialité, la disponibilité des serveurs, etc.

Les différences – explication longue :

J’ai divisé les différences en 3 aspects principaux:

A. Caractéristiques :
Certaines fonctionnalités n’existent pas dans gitlab.com (il y en a environ 40). Ceci est en fait dérivé du fait que vous n’avez pas le contrôle sur le serveur.
liste partielle :

  1. Intégration Active Directory/LDAP
  2. Note DevOps
  3. Modèles de fichiers d’instance
  4. Plugins
  5. Intégration Kerberos
  6. Git Server Hooks
  7. Accès auditeur
  8. et plus

Une liste complète peut être obtenue auprès de nous en nous contactant à devops.fr@almtoolbox.com
(La liste change de temps en temps et n’est pas disponible sur le site Web du fabricant).

B. Limitations:
Sur gitlab.com, il existe certaines limitations de temps/d’espace sur le stockage, la puissance de traitement, etc.
liste partielle :

  1. Limite de taille maximale du dépôt
  2. Limite d’appels API maximum par heure
  3. Limitation de la taille de stockage de toutes les informations du compte
  4. Une limite sur le temps d’exécution maximal pour CI si vous utilisez des coureurs publics dans le cloud
    et plus.

Une liste complète peut être obtenue auprès de nous en nous contactant à devops.fr@almtoolbox.com
(La liste change de temps en temps et n’est pas disponible sur le site Web du fabricant).

Remarque : sur gitlab.com, certaines des restrictions peuvent être annulées en payant un supplément pour le stockage et la puissance de calcul pour exécuter CI (plus d’explications dans la section suivante)

C. Aspects liés à l’octroi de licences et aspects financiers :
Première différence :
Sur gitlab.com, vous devez payer pour chaque instance séparément.
En autogéré, vous pouvez configurer 2 environnements distincts, et étant donné que les mêmes utilisateurs utiliseront les 2 environnements, vous ne pouvez payer qu’une seule fois pour chaque utilisateur – il n’est donc pas nécessaire de payer une double redevance !
Par exemple, vous pouvez l’utiliser pour créer un environnement intermédiaire pour les tests sur un nouveau serveur avant de le mettre à niveau.

Deuxième différence :
Sur gitlab.com, il y a des frais supplémentaires pour l’extension de stockage et pour recevoir une puissance de calcul supplémentaire pour recevoir des “minutes CI” (réception d’une puissance de calcul supplémentaire) et/ou exécuter CI sur des processeurs spéciaux.
Le paiement pour cela n’est généralement pas relativement élevé – mais d’un autre côté – c’est une dépense dont le coût total est difficile à estimer à l’avance (comme toute dépense dans le cloud).

Foire aux questions (FAQ) :

1)Question : Nous voulons un serveur GitLab dans le cloud, mais nous ne voulons pas le maintenir nous-mêmes. Existe-t-il une solution ?

Oui, il y a une solution. Dans cette situation, nous offrons un service géré où nous gérerons l’environnement pour vous.
Nous offrons une variété d’options à ce sujet – de la responsabilité des mises à niveau du serveur à l’assistance totale, y compris le SLA. Pour plus de détails, contactez-nous : devops.fr@almtoolbox.com  ou téléphonez au 01 84 17 53 28

Nous proposons également un service géré appelé “Apportez votre propre cloud” – où vous nous fournirez votre infrastructure dans le cloud (dans votre environnement préféré), et nous y construirons et maintiendrons votre environnement.

Il est important de rappeler qu’une solution “Self-managed” signifie que vous pouvez aussi mettre un serveur privé (single tenant) dans un cloud privé, et profiter ensuite de tous les mondes : les avantages d’un serveur privé et d’un infogéré de haute qualité service où vous n’avez pas à vous occuper de la maintenance du serveur et de l’environnement.

2) Question : La liste des différences fonctionnelles est longue et nécessite un long examen. Existe-t-il un moyen de raccourcir le test?

Oui, la réponse est oui. Il y a quelques années, nous avons écrit un article qui aide à choisir une édition GitLab dans le sens inverse (en utilisant la méthode d’élimination).

En plus de cela, nous pouvons vous aider à passer cet examen avec vous, avec l’aide de notre équipe d’experts pour GitLab et le cloud. Nous offrons un tel service – contactez-nous par e-mail devops.fr@almtoolbox.com  ou par  téléphone  au 01 84 17 53 28

3) Question : Nous voulons essayer GitLab dans le cloud / Autogéré. Est-ce possible et comment ?

Oui c’est possible. Contactez-nous et nous pouvons vous donner accès à l’expérience. Nous avons des environnements de tous types et avec toutes les fonctionnalités de GitLab.

4) Question : Quelles sont les différences entre les éditions qui se trouvent sur gitlab.com / Autogéré ?

GitLab est divisé en 3 éditions : Free, Premium, Ultimate. Tous les trois sont disponibles en mode autogéré et dans le cloud.

L’article suivant contient une liste complète de toutes les fonctionnalités de GitLab (plus de 500), divisées par versions.

5) Question : Nous utilisons actuellement GitLab Self-managed et souhaitons passer à gitlab.com – est-ce possible ?

Oui possible. D’après notre expérience, la question nécessite une certaine planification et un plan d’action, car il s’agit généralement d’un système utilisé par de nombreux utilisateurs, et il est important de le faire correctement et en toute sécurité.
En plus de cela – la facilité de transition est également liée à la version actuellement installée avec vous, car il n’est pas possible de passer d’une version à gitlab.com, donc plusieurs mises à niveau de version peuvent être nécessaires pour être prêt à passer au cloud .
Nous offrons un tel service de migration, basé sur notre expérience accumulée et les meilleures pratiques pour une exécution rapide et sûre.
Contactez-nous pour plus de détails par e-mail devops.fr@almtoolbox.com  ou par  téléphone  au 01 84 17 53 28

6)Question : Est-il possible de passer de l’un à l’autre ? C’est-à-dire de gitlab.com à GitLab autogéré, ou vice versa de l’autogéré à Gitab.com ?

Oui, les deux sens sont possibles. D’après notre expérience, la question nécessite une certaine planification et un plan d’action, car il s’agit généralement d’un système utilisé par de nombreux utilisateurs, et il est important de le faire correctement, rapidement et en toute sécurité.
Nous offrons un tel service basé sur notre expérience cumulée – n’hésitez pas à  nous contacter  par e-mail devops.fr@almtoolbox.com  ou par  téléphone  au 01 84 17 53 28

Quelques notes finales :

  • L’article est correct au moment de la rédaction de l’article (janvier 2023). À l’avenir, il peut y avoir des changements, bien sûr, et il est possible que certaines des fonctionnalités qui ne sont actuellement pas disponibles sur gitlab.com soient disponibles à l’avenir.
  • L’article n’a pas été écrit par AI. L’image d’illustration a été préparée avec l’aide de l’IA.

GitLab SaaS gratuit (gitlab.com) sera limité à 5 utilisateurs

Récemment, la société GitLab a annoncé que le niveau gratuit de GitLab SaaS (également connu sous le nom de “gitlab dot com”)
aura une limite de 5 utilisateurs par Namespace (**) à compter du 22 juin 2022.

gitlab logo

Cela signifie que si vous utilisez le niveau gratuit de gitlab.com et que vous avez plus de 5 utilisateurs, vous devez vous préparer et décider de vos prochaines étapes !

Que pourriez-vous faire ?

 

  1. Passez à l’une des éditions payantes – Premium ou Ultimate. Vous pouvez nous contacter pour en savoir plus sur les différences
  2. Envisagez l’édition Ultimate et utilisez un nombre illimité d’utilisateurs “invités”. Les utilisateurs invités ont des autorisations limitées, mais vous pouvez le trouver assez bon
  3. Envisagez l’édition Ultimate et utilisez un nombre illimité d’utilisateurs “invités”. Les utilisateurs ont des autorisations limitées, mais vous pouvez le trouver assez bon

Il y a plus d’options (dépend de votre environnement et de votre organisation) – contactez-nous pour plus d’informations

Il y a un plus d’options (dépend de votre environnement et de votre organisation) – contactez-nous pour plus d’informations

Vous pouvez toujours nous contacter et nous nous ferons un plaisir de vous répondre : devops.fr@almtoolbox.com ou +33 1 84 17 53 28
Nous sommes ALM-Toolbox, le partenaire officiel de GitLab en Europe et dans le monde. Nous fournissons des conseils GitLab, la migration, aidons les clients à choisir les licences les mieux adaptées, un hébergement privé, un support de qualité et rapide, le développement de modules complémentaires GitLab et nous soutenons et vendons une variété d’outils DevSecOps et ALM.

** Qu’est-ce qu’un espace de noms GitLab ?

Un espace de noms est un nom unique pour un utilisateur, un groupe ou un sous-groupe sous lequel un projet peut être créé. Cliquez ici pour en savoir plus.

 

Liens utiles:

 

GitLab SaaS gratuit (gitlab.com) devient limité à 5 utilisateurs

Récemment, la société GitLab a annoncé que le niveau gratuit de GitLab SaaS (également connu sous le nom de “gitlab dot com”)
aura une limite de 5 utilisateurs par Namespace (**) à compter du 22 juin 2022.

gitlab logo

Cela signifie que si vous utilisez le niveau gratuit de gitlab.com et que vous avez plus de 5 utilisateurs, vous devez vous préparer et décider de vos prochaines étapes !

Que pouvez-vous faire ?

Voici quelques-unes de vos options :

1.Passez à l’une des éditions payantes – Premium ou Ultimate. Vous pouvez nous contacter pour en savoir plus sur les différences
2. Envisagez l’édition Ultimate et utilisez un nombre illimité d’utilisateurs “invités”. Les utilisateurs invités ont des autorisations limitées, mais vous pouvez le trouver assez bon
3.Passez à GitLab auto-hébergé gratuit (cela vous permet d’utiliser autant d’utilisateurs gratuits que vous avez besoin). Nous pouvons vous aider avec la migration et le support.

Il y a plus d’options (tout dépend de votre environnement et de votre organisation) – contactez-nous pour plus d’informations

Des questions? Besoin de connaître les tarifs ou d’obtenir un devis ?

Vous pouvez toujours nous contacter et nous nous ferons un plaisir de vous répondre :  devops.fr@almtoolbox.com ou +33(0)1 84 17 53 28,   
Nous sommes ALM-Toolbox, le partenaire officiel de GitLab en Europe et dans le monde. Nous fournissons des conseils GitLab, la migration, aidons les clients à choisir les licences les mieux adaptées, un hébergement privé, un support de qualité et rapide, le développement de modules complémentaires GitLab et nous soutenons et vendons une variété d’outils DevSecOps et ALM.

 

** Qu’est-ce qu’un espace de noms GitLab

Un espace de noms est un nom unique pour un utilisateur, un groupe ou un sous-groupe sous lequel un projet peut être créé. Cliquez ici pour en savoir plus.

Liens utiles:

 

Construire une infrastructure à l’aide de Terraform

hashicorp terraform logo

Voici deux cas d’utilisation réels où nous avons aidé nos clients à créer une « Infrastructure en tant que code » à l’aide de Terraform.

1. Client dans le domaine  des économies d’énergie et de l’IoT

Le client dispose d’une application Web créée à l’aide de GitLab CI. Le client utilise AWS comme infrastructure avec Cloud Front, S3, Route 53 et un fournisseur DNS externe. Il  devait être capables de mettre en place un environnement rapidement et de manière cohérente sans « magie noire ».

L’outil que nous avons choisi avec le client était Terraform. En utilisant Terraform, nous avons créé toutes les ressources pour que l’application puisse s’exécuter. Nous avons traité des problèmes de sécurité (par exemple, le compartiment S3 devait être privé mais toujours accessible au CloudFront), de mise en cache et plus encore.

Nous avons utilisé le compartiment S3 pour conserver l’état de Terraform afin que le script puisse s’exécuter partout et nous avons utilisé DynamoDB pour nous assurer que le script Terraform ne s’exécutera pas en parallèle, même à partir de différentes machines.

Avec le script Terraform et l’espace de travail Terraform, le client peut désormais créer et gérer plusieurs environnements et peut être sûr que tous sont exactement les mêmes.

2. Client : solution commémorative basée sur le Web

Dans ce projet, nous avons utilisé Terraform pour contrôler l’infrastructure sur AWS et DigitalOcean.

Nous avons créé un cluster Kubernetes et utilisé l’intégration Terraform Helm3 pour installer des applications d’infrastructure telles que la surveillance et des bases de données telles que la recherche Elastic, MySQL et etc.

Sur AWS, nous avons créé l’infrastructure pour prendre en charge le client WEB qui comprenait Cloudfront et S3.

Le script Terraform prend en charge les variables d’environnement et utilise l’espace de travail Terraform pour pouvoir créer plusieurs environnements (Test et production)

Nous avons utilisé le compartiment S3 pour conserver l’état de Terraform afin que le script puisse s’exécuter partout et nous avons utilisé DynamoDB pour nous assurer que le script Terraform ne s’exécutera pas en parallèle, même à partir de différentes machines.

Besoin d’aide avec Terraform et pour appliquer ses meilleures pratiques ?
Nous représentons officiellement la société HashiCorp et nous fournissons des services de conseil, de formation, d’assistance, de services gérés et de vente de licences d’abonnement Enterprise / cloud.

Contactez-nous : terraform@almtoolbox.com ou appelez-nous : +33 1 84 17 53 28(France /Europe)

Exécution de Vault en tant que service sur HCP

Nous vous invitons a voir  cette  vidéo expliquant l’exécution de HashiCorp Vault en tant que service cloud géré.
Vault est un produit standard qui est désormais (de facto) une norme de protection des secrets d’entreprise.
La vidéo a été enregistrée dans le cadre de la conférence HashiConf.

Pour votre commodité, nous avons également ajouté le texte intégral sous le film vous pouvez ainsir lire le texte dans une deuxieme fenetre

Voir la video (14min):

Nous sommes spécialisés dans le conseil dans la transition vers les microservices tant en termes d’architecture qu’en termes d’infrastructure et de DevOps, et sommes expérimentés dans le démantèlement de monolithes, dans la conception, le téléchargement de solutions de microservices vers le cloud et la conception intégrée Kubernetes et conteneurs.

ALMtoolbox est le  représentant officiel de GitLab, Hashicorp  en France et dans d’autres pays.

Contactez pour nous toute question, un devis ou même une license d’évaluation.

ALMtoolbox : 01 84 17 53 28, devops.fr@almtoolbox.com

 

 

Transcript:

Welcome to HashiConf Digital 2020 and welcome to the Vault on HashiCorp Cloud Platform (HCP) presentation.

I’m Rand Fitzpatrick on the product management team here at HashiConf, and I’ll be joined a little bit later by
Thor Hansen on the engineering team to walk you through a bit of HashiCorp cloud platform’s Vault offering.

So we’re all relatively familiar with Vault, we’ve got a world-class tool for really helping you manage that transition from static infrastructure and dynamic infrastructure, and provide identity-based access and security
that’s necessitated to really secure that transition and the changing ephemeral workloads that we demand.

so HashiCorp delivers an entire stack of tools to help with these workloads across the cloud. Everything from Terraform, Vault, Consul and Nomad, and these all compose extremely well across the various workflows wherever you might use them in whichever cloud.

hashicorp-delivering-app-workloads

Vault however has been able to offer us a huge degree of flexibility and capability in making sure that you can
secure your applications as you scale out and build your environment in a more robust and secure way.

HashiCorp Vault

HashiCorp Vault is the world-leading solution for secrets management which is its most well-known capability for managing all of your secrets, credentials everything from PKI and other secure data that you would want to distribute across your application stack.
It’s also one of the world-leading solutions for data encryption with transit and transform, so all of your encryption workloads, both form preserving and otherwise enabled by Vault within your application path, and also broadly identity-based access to help secure all of your machine-to-machine connections using trusted identities and secure and auditable relationships.

Zero Trust

Generally extending this it’s the one machine authorization and authentication point to really connect all of your systems in a zero-trust world through identity-driven control.

Using Vault has always been a huge boot both on the open-source and enterprise sides. But sometimes it can take a little bit of effort to get up and running and get it customized for your specific use case.
HCP Vault or HashiCorp Cloud Platform Vault is entering private beta today to help get you directly to day zero of realizing value letting HashiCorp manage the operations and complexity to help you scale this out and get it used in the topologies that suit your application best.

What is HashiCorp Cloud Platform?

I know we’ve heard about this earlier today as well as earlier in the year when hcp Console was first announced but the true vision is that it takes care of the push-button deployment, infrastructure management, and multi-cloud workflows that are going to help you extend Hashicorp’s tools where are wherever you are in terms of your cloud deployment journey and scale with you as you grow.

So push-button deployment, all we need to do to instantiate a Vault cluster for use at this point is come into HCP once we’ve got an HVN which is the HashiCorp Virtual Network just instantiate a cluster and within 10 minutes usually faster we will have spun up a full production scale Vault cluster ready for your use. That infrastructure will be fully managed not only will we have its current state we’ll have its logs, we will have its status, the entire SRE teams for
HCP will be monitoring and making sure that it’s up to date and keeping it up with patches and version progression,
so you’re always using the healthiest and most well-secured version of Vault.
And in terms of really supporting those multi-cloud workflows hcp is going to have the same set of extensible capabilities and well-managed primitives that work wherever you are.

Now right now HCP is primarily on AWS but we’re rapidly expanding and you’ll be able to deploy this wherever you need your workloads,
so on top of that hcp platform we’re bringing you hcp Vault which is really our best attempt to offer you Vault ready to go, ready to securely support your dynamic infrastructure.

We’re going to get a little bit into the specifics before I hand it off to Thor about how we’re actually bringing this to you in a way that’s going to support your infrastructure. So I mentioned earlier that we’ve got HVN these are the HashiCorp wrapper over an isolated network and compute environment we support a fully replicated Vault
cluster with integrated storage and replication within that environment, and that environment is owned entirely
by the end-user. The only things running in there end up belonging under an account for that end-user and it’s a
very secure space.
The control plane for the HashiCorp cloud platform will exercise command actions that can help reconverge and recover and always make sure that your systems are in a well-running state, and we can scale out from here,
to make sure that as your capacity needs grow we can increase the horizontal and vertical scalability of these clusters to meet both your storage needs your throughput needs and your processing needs, depending on how your workloads are right across static secrets dynamic secrets, and encryption type workloads.

Also in these environments are secure snapshots and restore capabilities and audit logging to make sure that as you go through your Vault life cycle we can always make sure that you have the data that you need to recover as well as maintain your audibility and data retention requirements.

As you connect this with your infrastructure we offer a number of secure pathways everything from the current modality of VPC peering to more direct connections through VPNs and other network topologies this is to make sure that wherever you use your infrastructure HCP Vault can be there to support you, and as I mentioned we really want to focus on getting you to day zero value so instead of working to right-size your cluster working to make sure that your storage and backup workflows are well-executed, you can really just instantiate a Vault cluster; export some environment variables and
through the Vault client immediately get up and running and connected to your Vault cluster and start using it.

Vault in Production

So what does this allow us to do? instead of worrying about all the operations you can jump directly to your production needs you can start focusing on what it means to develop against Vault and get it integrated into your environment it can help you focus on understanding what off methods and secrets engines and policies are going to be useful in supporting your application environment, rather than focusing on the operations work up front.

Likewise, we’ll offer lightweight developer services to help you test with Vault learn Vault and integrate it into your applications without having to impact your full-scale production clusters. All of these available dynamically within your HVN on HCP.

Reliability

Additionally, you’ll be able to rely on HCP for all of that resilience and scale as well as best of breed hardening to
help you keep your systems orchestrated and healthy so you can worry about what your application is meant to do rather than the care and feeding of Vault itself.

Enable the future

Finally, we help enable the future with secure integration. HCP makes it easier to stay up to date with new versions of all as they go, updating seamlessly behind your application façade, as well as being able to take advantage of additional capabilities that we build onto the platform as HCP grows and develops over time.

To dive into a little bit more of the detailed usage of HCP Vault as we’re rolling it out today, going to hand it off to Thor Hansen.

Demo time (08:40)

Hi, I’m Thor Hanson. I’m an engineer here at HashiCorp. I’m going to give you a demo today on Vault on HCP. what we’re going to do is we’re going to create a virtual network we’re going to create a Vault cluster inside that network then we’re going to use an EKS cluster on AWS, and we are going to inject secrets into a pod that we create on that cluster – so let’s dive in.

So here we have HashiCorp Cloud Platform. We’ll be walking with an overview page – where we can see setup steps, as well as other things that we can create on the platform like Consul.
We’re going to go and create a virtual network. We can select a name; a region a CIDR Block, and then we’ll create the network. This will take a couple of minutes to initialize but once it is we’ll have our HVN as we call it.
The next step we can do with our HVN is to create a Vault cluster inside the network, so go ahead and click that.
Then we can name our cluster; we can put it in a region and then we can click the blue button to just simply create the cluster inside our HVN. That will take a couple minutes but then we’ll be presented with our Vault cluster.

We have our Vault configuration where we can generate a token get the address of the cluster we can see the version, the configuration options we’ll have getting started with Vault section where people who are newer to Vault can learn how to use it. We can see the cluster stable and then the assigned network that we created the cluster inside.

so after all that, what we can do next is we’ll go back to our HVN and we will select peering connections. This allows us to peer the HVN with a AWS VPC, so what we’ll do is we’ll copy in our AWS VPC information into this peering connection helper. We’ll grab the account ID; the VPC ID ; the region that the VPC is in, and then we’ll also copy in the VPC CIDR block.
Then we’ll create click create the connection you’ll see that this goes from creating to pending acceptance so that means we just have to hop on over to our AWS control panel, into the peerings tab and we can go and click accept request.
We can check to make sure that all the settings are correct and that this is the connection that we established then we can click yes accept. Once that’s been created that means now that our vpc and the hvn are appeared so we can go back in and see that the connection is now active.

Route table

The last step is to go back to our VPC and create a route table. This route table will allow us to map a CIDR Block from the vpc into our HVN, so we’ll go ahead and create one of those. Give it a name and then we’ll go back into the panel and we’ll create a route for it.
Let’s go into the routes tab we’ll hit edit routes, then we can add a new route which will be the HVN’s HPC CIDR block so we’ll copy out that CIDR block; use that as our destination, and then as the target we’ll use the peering connection that we’ve created.
This should auto-populate by was there it is so we’ll click accept now we’ve created a route from our VPC to our HVN, and vice versa. This will allow us to access the Vault cluster from our VPC.
Last thing to do, is we can go back to our Vault cluster and we’ll generate an admin token. so this will generate a token we copy that out and this will allow us to access the Vault cluster.

So we’ll go back to our EKS cluster in our VPC we’ll create a Vault namespace, and then we’ll create a couple of Kubernetes objects like a service account a cluster role and a cluster role binding. these will allow us to configure the Kubernetes off backend in Vault to access Vault from Kubernetes so create those things the next thing we’re going to do is we’re going to copy out the access token that’s created under the service account, we’ll use this
access token when we configure the Kubernetes auth endpoint. so here you can see we’ve successfully grabbed the jwt off token.

Vault CLI

So the next thing that we are going to do is we are going to create a pod that we can exec into to run the Vault CLI. If you recall we had to peer our Vault our HVN with this VPC, so that’s the only way that we’re able to access the Vault cluster so we’re going to create a container that we can exec into and then we’ll be able to set up our Vault cli to access our Vault cluster that’s been paired with this vpc. so you’ll see here we’ll set up the Vault address we’ll set up the Vault namespace we’re going to import some of the information that we copied out from Kubernetes earlier like the jwt as well as the ca certificate from EKS. These things aren’t for the Vault cli but they’ll be helpful when we set up our kubernetes auth back end so now we’re going to log in using the token that we copied from the control plane webpage to begin with now that we’re logged in, we can enable the Kubernetes auth backend. Now that’s enabled we need to configure it we’ll use the jwt and the ca search that we talked about before and then we’ll create a role that gets assigned when our future app will log in under that auth method, and then we’ll enable the secrets engine and we’ll write a little HashiCorp secret to that secrets engine that our app can get injected into it later. and then lastly we’ll create a role that will allow us to access that secret in Vault. Great! so now we’ve done all those things the last thing we need to do is now set up our Vault agent injector we’ll use helm to do this we’ll use the HashiCorp helm resource we will enable or we’ll install it via helm setting our Vault external address to be in our hcp Vault cluster
and then last we have our application you’ll notice in the annotations of this application that it has directives on
how to grab secrets where to grab them from and where to store them. once we create that we can see that the
the app is now running which means a secret has successfully been injected into that pod. and so then we can exec into that pod and look uh to see if our secret has been successfully copied into a file there so we’ll just cat it out at Vault secrets slash kv-secret and there we can see hashicomphrox

Epilog

So that’s been a really quick demo on how we can quickly inject secrets into an eks cluster by simply peering a vpn connection and then treating the Vault on hcp like we would any other Vault that we had running elsewhere
this can be really powerful because it doesn’t require you as the end-user to have to set up Vault to manage it to deal with scaling it out or scaling it down our whole team constantly monitors this we have long-running workflows that keep it constantly updated keeping constantly going and so we’re really excited for you guys to try this out and to tell us what you think.

Atlassian a changé les règles. Que faire?

Dans l’article suivant, nous soulignons les options d’action basées sur les dernières mises à jour d’Atlassian qui ont étonné et mis en colère la communauté des utilisateurs d’Atlassian en Europe  et dans le monde (et nous en faisons partie)  et pour des raisons qui lui sont propres  a décidé d’éliminer ses produits  on  premise.

Étant donné que nous prenons en charge de nombreux clients on premise, nous avons reçu ces dernières semaines des dizaines de demandes avec la question “Que faisons-nous maintenant?”

Notre recommandation était d’attendre un peu (si possible) car il n’est pas nécessaire de prendre une décision urgente, et il vaut mieux voir si la situation  s’éclaircit après un certain temps. Maintenant, que les choses sont  devenues plus claires  et dans l’article ici, nous écrivons  pour la première fois des instructions et des options relatives à Jira et aux outils alternatifs (et plus tard, nous publierons des articles sur Bitbucket et Confluence).

Le message d’Atlassian en bref :

Le 16 octobre, Atlassian a publié une déclaration officielle disant (brièvement) ce qui suit:

Ils arrêtent de développer les produits suivants:

  • Jira Server
  • Jira Software Server
  • Bitbucket Server
  • Confluence Server
  • Crowd Server
  • Bamboo
  • Jira Service Desk Server
  • Il sera possible d’acheter de nouvelles licences pour les produits ci-dessus jusqu’au 1/2/2021 (le  prix des renouvellements augmentera  et le support des  innovations)
  • Le support et les mises à jour pour les produits ci-dessus peuvent être achetés jusqu’au 2/2/2022
  • Arrêt du support produit (et clôture définitive et complète) le 2/2/2024
  • Il sera possible d’acheter des applications tierces sur leur marketplace jusqu’au 02/02/2023

Il est recommandé de lire l’annonce officielle du fabricant – c’est celle qui est déterminante (lien vers celle-ci en fin d’article).

Que peut-on faire avec Jira à partir de maintenant?

  1. Vous pouvez accéder au cloud public Atlassian. Nous aidons les entreprises à explorer les significations et les coûts, et savons également comment réduire les coûts de toutes sortes de façons – j’ai inclus une astuce sur le sujet dans les liens à la fin de cet article.
  2. Vous pouvez basculer vers les solutions de centre de données d’Atlassian (il s’agit en fait d’une solution à haute disponibilité qui peut être exécutée sur site ou dans le cloud), mais il est important de garder à l’esprit que les prix peuvent être considérablement plus élevés.
  3. Il est possible de rester sur Jira Server (même si on s’attend à ce qu’il cesse d’évoluer et de se mettre à jour). Nous proposons notre propre support produit comme nous l’avons fait ces dernières années.
  4. Et on peut bien sûr envisager au-delà d’autres outils

Si vous ne souhaitez pas rester avec Atlassian Jira, vous avez le choix entre plusieurs options:

Nous avons divisé les options ici en 2 catégories: votre propre serveur privé ou cloud.

Toutes les options ici incluent des outils que nous connaissons bien; les outils que nous avons testés et ceux que nous représentons et leur proposons un support, des formations, des licences et plus encore.

Nous avons divisé les options ici en 2 catégories: votre propre serveur privé ou cloud.

Toutes les options ici incluent des outils que nous connaissons bien; Les outils que nous avons testés et ceux que nous représentons et leur proposons un support, des formations, des licences et plus encore.

Si vous préférez votre propre serveur (auto-hébergé / sur site):

  • GitLab – GitLab a la capacité de gérer des tâches en plus du code et de la gestion CI / CD afin que tout soit dans un seul package (plus d’informations ici). Nous sommes officiellement certifiés pour soutenir le produit depuis 2017, et les représentants officiels de GitLab en France et dans d’autre pays.
  • Taiga – un outil relativement ancien, basé sur l’open source. Nous sommes qualifiés pour fournir un support technique pour le produit (en coopération avec le fabricant). L’outil est destiné à ceux qui souhaitent passer à des méthodes agiles telles que Agile, Scrum, Kanban, etc. et qui recherchent un remplaçant pour des outils tels que Jira ou Asana. Nous sommes les seuls représentants officiels du produit en Israël. Plus de détails peuvent être lus ici.
  • OpenProject – Un ancien outil basé sur l’open source, conçu pour gérer des projets et des tâches qui ne sont pas nécessairement basés sur Agile (et les produits ne sont pas nécessairement du code). Nous sommes les seuls représentants officiels du produit en Israël. Plus de détails peuvent être lus ici.
  • Azure DevOps – gestion des tâches, gestion de code basée sur git, gestion des tests et CI / CD afin que tout soit dans un seul package (ancien basé sur TFS).
  • HCL Compass – Gestion de tâches et de projets – un outil riche avec une variété de capacités et de personnalisations pouvant être effectuées, similaire à Jira.
  • Managed ClearQuest – un produit que nous supportons depuis plus de 20 ans.

Si vous préférez une solution cloud plutôt que d’avoir votre propre serveur:

GitLab – Similaire à ce que est écrit ci-dessus

  • Taïga – ibid
  • OpenProject – ibid
  • Azure DevOps – ibid
  • ClickUp – un outil de partage qui comprend des documents, des tâches, des discussions, des destinations et plus
  • Miro – un outil innovant pour la planification des tâches, la collaboration entre les personnes, le travail agile et plus
  • Trello – Gérez facilement les tâches et les projets (généralement pas pour les projets complexes)
  • Managed Compass (serveur géré privé dans le cloud)
  • Managed ClearQuest (cloud privé et géré)

Nous savons  que la sélection est large… donc dans un futur proche vous pouvez nous contacter par email à l’adresse suivante devops.fr@almtoolbox.com pour  que nous vous aidions  à trouver l’outil qui correspond le mieux à vos besoins.

Pour certains des outils, nous avons également un environnement «sandbox» à expérimenter, et s’il est disponible, nous pouvons vous en donner un accès temporaire.

Conseil: Parfois, la meilleure façon de choisir rapidement l’outil qui vous convient est de définir des critères pondérés, puis d’effectuer une sélection préliminaire pour sélectionner quelques outils “finalistes”, puis d’effectuer un examen plus approfondi de ces outils finaux.

L’équipe d’ EGDS ALM-Toolbox est expérimentée dans tous les outils ci-dessus et travaille avec ALM et DevOps depuis plus de 15 ans. Nous pouvons vous aider sur les aspects suivants:

Aide à choisir les bons outils pour votre organisation

Aide à la sélection de la licence la plus appropriée en fonction des besoins

Passer à de nouveaux outils et transférer du matériel rapidement et en toute sécurité (migration)

Au-delà du cloud (Jira Cloud) et examinez si votre environnement actuel peut réellement passer au cloud

Connecter les outils et les adapter aux processus de développement – en particulier avec git, Jenkins, Kubernetes, des outils de chat (tels que Slack / Mattermost) et plus

Planification et construction de processus complets de développement et de DevOps, qui incluent à la fois l’aspect méthodologique et la combinaison des outils eux-mêmes – y compris la gestion de code, CI / CD, révision de code et processus d’analyse de code pour améliorer la sécurité du code que vous développez ou utilisez

Conseils et conseils dans les étapes de mise en œuvre
Support technique (y compris l’option SLA)
Pour plus de détails contactez-nous: devops.fr@almtoolbox.com ou par
téléphone: 01 84 17 53 28

Et qu’en est-il de Bitbucket et de Confluence?

Dans le prochain article, nous écrirons  sur les directions possibles pour les alternatives Bitbucket. Vous pouvez nous envoyer un e-mail (à l’adresse ci-dessus) si vous souhaitez recevoir une mise à jour dès sa sortie (ou contactez-nous maintenant si le problème est urgent  pour vous).

Liens pertinents:

L’annonce officielle d’Atlassian

 

 

Enregistrement: Protection avancée des données pour les services bancaires et financiers utilisant Vault

vault

Nouveau!!

En tant que gardiens des choses de valeur, les institutions financières traitent depuis longtemps des problèmes de cybercriminalité, ce qui en fait l’un des principaux risques auxquels le secteur est confronté. Cependant, alors que les organisations passent au cloud et que les menaces deviennent de plus en plus sophistiquées, comment protégez-vous les données les plus sensibles, même dans des environnements non approuvés? Au cours de cette session, nous explorerons comment HashiCorp Vault fournit la base de la sécurité du cloud. En offrant des fonctionnalités avancées de protection des données telles que le chiffrement en tant que service avec le chiffrement à préservation du format (FPE), le masquage des données via le moteur de secrets Transform, l’intégration de KMIP et HSM, Vault augmente l’agilité pour déployer une cryptographie nouvelle et isolée et, en même temps , réduit les coûts et les risques.

Auteur : Russ Parsloe, Staff Solutions Engineer, HashiCorp

Dans ce webinaire, vous apprendrez à:

  1. Comprenez les défis de sécurité importants grâce à la protection et au chiffrement avancés des données dans les environnements traditionnels et cloud
  2. Protégez les charges de travail et les données sur les systèmes, les clouds et l’infrastructure traditionnels
  3. Protégez les données dans les bases de données d’entreprise (par exemple MySQL, MongoDB, etc.), les systèmes de stockage d’entreprise (par exemple NetApp) et les plates-formes informatiques (par exemple VMware)

Regarder la video: