BeardOx - "Automatiseur" spé Powershell

Salut à tous,
Moi c’est Quentin, la trentaine, 2 nains et bientôt jeune marié.
Dans la vie je suis (récemment) ingénieur Systèmes et bientôt DevOps (pour l’étiquette).
Parce que depuis plusieurs années désormais je suis spé dans ma société en automatisation (scripting) plus particulièrement en Powershell.

Je pense souffrir du syndrome de l’imposteur car pour moi je ne fais pas du devops, étant donné que ma boite est une ESN qui propose des services d’intégration et d’infogérance. Pas de développement.
Cependant je fais l’interface entre mes collègues “Ops” et les avant-vente, afin d’optimiser nos process d’intégration et surtout les automatiser au max. Etant donné que majoritairement notre parc client est Windows le Powershell s’est vite imposé. Et ca tombait bien j’en faisais déjà avant dans mes précédentes expériences !
Le fait que nos clients soient très hétérogènes (ESN toi-même tu sais trololol) “m’oblige” à penser très modulaire et compatible avec la majorité des machines.
En dehors de ça je fais partie du service Support/Centre de services N3 systèmes, je fais donc du tickets et du debug !

Voili voilou. En ce moment on est sur un projet d’envergure dans ma boite, dont mon binôme et moi sommes “initiateurs” (j’aime pas trop dire ça mais c’est ainsi ^^" en gros on a été dire “votre boite c’est la merde chef !” Au patron, et nous avons été entendus !), on essaye de restructurer et affirmer de nouvelles méthodologies dans l’entreprise. On a donc la chance d’avoir pu faire entendre nos voix et faire entendre qu’un service d’industrialisation (pour le coup, DevOps), s’imposait.
Petit projet annexe en ce moment, mise en place de Gitlab en interne. Nous étions auparavant sur Azure Devops mais je préfère passer sur une solution que nous pouvons maitriser en interne (ce qui va à contresens de ce que nous vendons en ce moment, du “tout cloud”, “tout SaaS”, mais je m’en fiche ^^).

Breeeeeeef, avec tout ça j’ai l’impression d’avoir la grosse-tête à parler de moi mais du coup la présentation: check
J’ai découvert les compagnons du devops via le Podcast et des recherches sur Gitlab ^^

3 « J'aime »

Bienvenue @beardox,

Content que tu es trouvé le forum grâce aux contenue GitLab et DevOps que @Lydra produit.

Pour moi à partir du moment où tu a un état d’esprit DevOps comme je l’apprend dans ma formation DevOps Mindset tu fais ton travail en adoptant le mouvement DevOps.

Si tu met de la coopération là ou il n’y en avait pas avant (Ops et Sales), que tu fluidifie les processus grace à de l’automatisation ou que tu partage la culture alors tu es sur la bonne voie. Il faut travailler ça et ne pas l’oublier.

Je suis curieux que votre ESN mette en place un GitLab interne, ce n’est pas votre cœur de metier et cela semble éloignée des compétences majoritaire dans votre société, vous semblez plus proche du monde windows que Linux.

Pourquoi ne pas avoir commencé justement par un SaaS GitLab ou une offre info-géré ? Histoire de commencé par la prise en main utilisateur de GitLab avant d’intégré la partie administration ? Cela doit avoir un sacré coût pour votre entreprise entre la montée en compétence et la mise en place ?
Vous le faite en infra as code ?

Si jamais vous avez besoin d’aide ou de conseils ponctuels sur GitLab et son administration vous pouvez faire appel à nos service car nous commençons à avoir pas mal d’experience dans son administration.

D’ailleurs que pense tu des Release Notes GitLab, est-ce que cela vous aide ?
Je tourne la 16.10 cette après midi.

Salut !

Merci pour ton retour, en effet on essaye d’appliquer la philo DevOps. On est une ESN à l’ancienne (mais pas nous :slight_smile: ) avec quelques dinosaures qui avaient l’habitude de choisir et décider tout seuls. Donc on se traîne quelques choix techniques qui personnellement ne me conviennent pas. Le SaaS est bien du moment qu’on le maîtrise de bout en bout. Ce n’est pas le cas avec les GAFAM (quand ils certifient des données en France et que l’IP du serveur est géolocalisée en Ireland par ex.).

J’essaye de pousser la partie sécurité et DevOps, parce que c’est ce qui me fait kiffer ^^!

Pourquoi notre ESN a choisi d’internaliser ? C’est quelque chose que je veux essayer de provoquer chez nous en interne. Il faut internaliser les données qui nous sont sensibles. Notre groupe projet a donc décidé l’internalisation car on est plusieurs à avoir des compétences Docker et que c’est la techno qu’on a choisi pour ce projet.

Ça me permet de répondre à l’autre de tes questions, pas d’IaC pour l’instant, pas vraiment.

On est sur une VM Alpine + Docker rootless + gitlab et runners en conteneurs (non définitif car on a pas encore tout testé).

EDIT: Je me rends compte que je n’ai pas répondu à tout ton message, désolé !
Du coup:

Pourquoi ne pas avoir commencé justement par un SaaS GitLab ou une offre info-géré

Le tarif, notre boite a fait beaucoup d’investissements ces dernières années qui se sont avérés des semi-échecs ou des outils peu utilisés au final. On veut d’abord prouver qu’on maitrise le sujet, que ça a un intérêt productif et financier, ensuite surement nous pourrons prétendre un investissements dans une version SaaS :slight_smile:
Pour Froggit, j’ai découvert y’a quelques jours lorsque j’ai découvert les compagnons du devops, j’ai fouiné un peu et ça a l’air top ! Beau boulot, j’aimerais tellement bosser dans une boite comme celle-ci ^^

Cela doit avoir un sacré coût pour votre entreprise entre la montée en compétence et la mise en place ?

La montée en compétences on la fait nous-mêmes, on est assez autodidactes comme souvent dans notre milieu.
La mise en place, on a une infra PoC pour le moment sur laquelle on va faire tourner tout ça le temps de mettre en place nos standards de fonctionnement et ensuite pousser ça sur l’infra interne.

Merci beaucoup pour la proposition d’aide ! J’y penserais !

Savez-vous qu’il y a des fournisseurs SaaS qui ne sont ni des GAFAM, ni même américain pour certain services. Par exemple pour GitLab nous avons créer Froggit et nous ambitionnons de fournir à nos client leur données pour qu’ils soient autonome au besoin. En aviez vous entendu parlé ?

Je vous suggère de remplacer alpine par des Debian slim, c’est a peine plus gros mais vous profiter de l’écosystème et de la communauté Debian.
Si votre GitLab est seul sur un serveur oubliez Docker, ce n’est pas pertinent, on parlais des méthodes d’installation ici. Pour le GitLab runner conteneurisé cela parai être une bonne idée, nous somme partit aussi sur ça pour Froggit, mais à l’usage ce n’est pas pratique et le runner fige parfois sans que l’on sache pourquoi, surtout dans la machine n’a plus trop de ressource. Nous mettons en place un nouveau runner directement sur la machine même si on est en exécuteur docker et que les jobs tournent dans des conteneurs.

1 « J'aime »

Alors oui, on sait (enfin je dis on, mais je parle de moi et mon binôme ainsi que les quelques collègues qui s’intéressent un peu à la souveraineté) que ça existe en mode Français, mais disons que pour notre société actuellement tous les outils utilisés sont Americains…si j’étais seul décisionnaire je dégagerais tout ça, malheureusement c’est l’héritage que nous avons :confused:
Je rêve d’une ESN qui renverse un peu les codes et qui prone l’OpenSource et 100% Français.

Pour l’anecdote, j’ai proposé Alpine parce que c’est un OS que j’affectionne beaucoup et qu’il permet d’avoir une certaine stabilité et sécurité sans trop de config, du à sa politique du “le moins est le mieux”.
Oui ma boite fait que du Windows mais en dehors j’aime beaucoup Linux depuis quelques temps déjà et mes collègues aimeraient aussi que nous arrivions à vendre ce genre de service également :smiley:
On a fait tout la conf déjà et les MODOP pour cet OS, ta proposition est pertinente mais pour le moment je pense que vu le temps investi dessus on va y rester :confused:

OK, je me le note, je proposerai en effet cette modification à mes collègues. On était parti dans l’idée d’avoir le Gitlab conteneurisé pour se faciliter les màj et donc la maintenance. C’est, je dois l’avouer, l’avantage premier que je vois à la conteneurisation. Hormis sa souplesse évidente.
Merci pour le REX sur l’usage pour les runners !! C’est bon à savoir. D’ailleurs, je ne suis pas sur d’avoir compris le fonctionnement des runners. Je l’avais configuré sur un mode docker. Du coup, son fonctionnement c’est quoi ? Un DinD ?
J’ai encore un peu de mal avec toutes ces notions et les confs possibles, mais ça va rentrer :wink:

PS: j’ai édité ma précédente réponse j’avais oublié des morceaux :smiley:

Salutations et bienvenue :wave:

C’est cool de voir des personnes faire du Powershell dans un cadre qui veut aller vers le DevOps c’est rare ça donne de la diversité !

2 « J'aime »

Salut DamyR et merci :pray:
On a une équipe atypique donc on fait les choses de manière atypique ! Du moment que le résultat est là :smiley:

2 « J'aime »