CérénIT

Je ne peux résister à mentionner la sortie de l’épisode 100 du BigDataHebdo, podcast où j’ai le plaisir de contribuer. Pour ce numéro spécial (épisode 100 et 6 ans du podcast), nous avons fait appel aux membres de la communauté pour partager avec nous leur base de données favorite, la technologie qui les a le plus impressionée durant ces 6 dernières années et celle qu’ils voient comme majeure pour les 6 prochaines années. Allez l’écouter !

Cloud

• Announcing the Terraform Visual Studio Code Extension v2.0.0 : Hashicorp prend en main le support de l’extension Terraform pour VSCode, en sort une nouvelle version et apporte différentes améliorations comme un meilleur support de Terraform 0.12 et l’utilisation du Terraform Language Server.

Container et orchestration

• Introducing the Telegraf Operator: Kubernetes Sidecars Made Simple : Présentation de l’operator kubernetes pour telegraf qui permet de déployer un agent telegraf sous la forme d’un sidecar dans un pod et de récupérer les métriques associés.
• Kubernetes 1.18.x officiellement disponible chez OVHCloud
• Longhorn Simplifies Distributed Block Storage in Kubernetes : Rancher vient de sortir la version 1.0 de Longhorn. C’est une solution de stockage pour Kubernetes que l’on peut utiliser avec ou sans Rancher. Il faut la voir comme une solution de stockage légère et simple à mettre en oeuvre. Un système de réplication permet d’éviter les pertes de données et d’amélioer la durabilité des données. Des fonctionnalités de backup/restore existent également. Elle semble plus simple à mettre en oeuvre que Rook/Ceph par ex mais sera moins complète que ce dernier.
• Understanding Kubernetes & Understanding Istio : Aurélie Vache réalise des sketchnotes pour vulgariser Kubernetes et Istio. Un joli travail de vulgarisation.

IoT

• 8GB Raspberry Pi 4 on sale now at $75 : Le Raspberry Pi 4 arrive en version 8Go de RAM, Raspberry PI OS arrive en 64 bits, le support du boot sur usb arrive aussi (adieu la SDCard) et plein d’autres choses. Le tout au prix de 75$.

Ops

• Sismology: Iguana Solutions’ Monitoring System : retour d’expérience sur une plateforme de monitoring initiée sur Prometheus et qui évolue vers VictoriaMetrics en prenant les aspects de stockage à long terme, le multi-tenant et la haute disponibilité de la plateforme.

Time Series

• Release Announcement: InfluxDB 2.0.0 Beta 12 : une beta de plus avec l’ajout notamment d’influx stacks pour faire du CRUD sur des groupes de ressources InfluxDB (dashboard, labels, tasks, etc).
• Warp 10, The Most Advanced Time Series Platform, now provides multi-architecture docker images. : vous pouvez donc déployer des images docker warp10 sur des plateformes amd64/armv7/arm64.
• May 2020: Warp 10 release 2.6.0 : Pleins d’améliorations et de correctifs et notamment la capacité de dialoguer directement avec Warp10 via le protocole Protobuf ou via Arrow.
• Time series forecasts in WarpScript : Présentation de l’extension Warpscript permettant d’appliquer des algorithmes de prévisions (ARIMA, SARIMA, HOLTWINTERS, etc) sur des séries temporelles. Précision: il s’agit d’une extension propriétaire mais vous pouvez l’évaluer sur la sandbox Warp10 mise à disposition par SenX.

Depuis que j’ai migré des sites sous kubernetes, j’avais perdu l’automatisation du déploiement de mes conteneurs. Pour ce site, je modifiais donc le site et une fois le git push realisé, j’attendais que Gitlab-CI crée mon conteneur. Je récupérai alors le tag du conteneur que je mettais dans le dépôt git où je stocke mes fichiers de configuration pour kubernetes. Une fois le tag mis à jour, je pouvais procéder au déploiement de mon conteneur. Il était temps d’améliorer ce workflow.

Gitlab propose depuis un moment une intégration avec kubernetes mais je lui trouve quelques inconvénients au regard de mes besoins :

• Il faut créer un compte avec un ClusterRole cluster-admin et je ne suis pas super à l’aise avec cette idée,
• Il est nécessaire de déployer Helm encore en version 2 alors que je suis passé en version 3 pour les rares projets où je l’utilise,
• L’ingress s’appuie sur nginx-ingress, alors que j’utilise Traefik,
• Je n’ai pas l’usage des autres fonctionnalités fournies par Gitlab dans mon contexte de “cluster de test” hébergeant quelques sites et applications web.

Mon besoin pourrait se résumer à pouvoir interagir avec mon cluster au travers de kubectl et de pouvoir y déployer la nouvelle version du conteneur que je viens de créer. Cela suppose alors d’avoir 3 choses :

• le binaire kubectl accessible sous la forme d’un conteneur ou directement en shell dans le runner,
• un fichier kubeconfig pour m’authentifier auprès du cluster et interagir avec,
• la référence de l’image docker fraichement crée par Gitlab-CI à appliquer sur un Deployment kubernetes.

Création d’un compte de service avec authentification par token

Utilisant le service managé d’OVH, je n’ai pas accès à tous les certificats du cluster permettant de créer de nouveaux comptes utilisateurs. Par ailleurs, pour les intégrations comme Gitlab, il est recommandé d’utiliser des Service Accounts. C’est ce que nous allons faire.

En plus du Service Account, il nous faut donner un rôle à notre compte pour qu’il puisse réaliser des actions sur le cluster. Par simplicité pour ce billet, je vais lui donner les droits d’admin au sein d’un namespace. Le compte de service pourra alors faire ce qu’il veut mais uniquement au sein du namespace en question. En cas de fuite du compte, les dégats potentiels sont donc moindres qu’avec un compter qui est admin global du cluster. Le rôle admin existe déjà sous kubernetes, il s’agit du ClusteRole admin mais qui est restreint à un namespace via le RoleBinding.

Créons le fichier gitlab-integtration.yml avec ces éléments :

---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: gitlab-example
  namespace: example
---
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: RoleBinding
metadata:
  name: gitlab-admin
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: admin
subjects:
- kind: ServiceAccount
  name: gitlab-example
  namespace: example

Déployons notre configuration sur le cluster :

# Apply yml file on the cluster
kubectl apply -f gitlab-integration.yml
serviceaccount/gitlab-example created
rolebinding.rbac.authorization.k8s.io/gitlab-admin created

Pour alimenter notre fichier kubeconfig, il nous faut récupérer le token :

# Get secret's name from service account
SECRETNAME=`kubectl -n example get sa/gitlab-example -o jsonpath='{.secrets[0].name}'`
# Get token from secret, encoded in base64
TOKEN=`kubectl -n example get secret $SECRETNAME -o jsonpath='{.data.token}'`
# Decode token
CLEAR_TOKEN=`echo $TOKEN |base64 --decode`

En prenant votre fichier kubeconfig de référence, vous pouvez alors créer une copie sous le nom kubeconfig-gitlab-example.yml et l’éditer de la façon suivante :

apiVersion: v1
clusters:
- cluster:
    certificate-authority-data: <Existing certificate in a base64 format from your original kubeconfig file>
    server: <url of your k8s http endpoint like https://localhost:6443/ >
  name: kubernetes # adjust your cluster name
contexts:
- context:
    cluster: kubernetes # adjust your cluster name
    namespace: example # adjust your namespace
    user: gitlab-example # adujust your user
  name: kubernetes-ovh # adujust your context
current-context: kubernetes-ovh # adujust your context
kind: Config
preferences: {}
users:
- name: gitlab-example # adujust your user
  user:
    token: <Content of the CLEAR_TOKEN variable>

Vous pouvez tester son bon fonctionnement via :

# Fetch example resources if any:
kubectl --kubeconfig=./kubeconfig-gitlab-example.yml get all
...
# Check you can't access other namespaces information, like kube-system:
kubectl --kubeconfig=./kubeconfig-gitlab-example.yml get all -n kube-system
Error from server (Forbidden): pods is forbidden: User "system:serviceaccount:example:gitlab-example" cannot list resource "pods" in API group "" in the namespace "kube-system"
Error from server (Forbidden): replicationcontrollers is forbidden: User "system:serviceaccount:example:gitlab-example" cannot list resource "replicationcontrollers" in API group "" in the namespace "kube-system"
Error from server (Forbidden): services is forbidden: User "system:serviceaccount:example:gitlab-example" cannot list resource "services" in API group "" in the namespace "kube-system"
Error from server (Forbidden): daemonsets.apps is forbidden: User "system:serviceaccount:example:gitlab-example" cannot list resource "daemonsets" in API group "apps" in the namespace "kube-system"
Error from server (Forbidden): deployments.apps is forbidden: User "system:serviceaccount:example:gitlab-example" cannot list resource "deployments" in API group "apps" in the namespace "kube-system"
Error from server (Forbidden): replicasets.apps is forbidden: User "system:serviceaccount:example:gitlab-example" cannot list resource "replicasets" in API group "apps" in the namespace "kube-system"
Error from server (Forbidden): statefulsets.apps is forbidden: User "system:serviceaccount:example:gitlab-example" cannot list resource "statefulsets" in API group "apps" in the namespace "kube-system"
Error from server (Forbidden): horizontalpodautoscalers.autoscaling is forbidden: User "system:serviceaccount:example:gitlab-example" cannot list resource "horizontalpodautoscalers" in API group "autoscaling" in the namespace "kube-system"
Error from server (Forbidden): jobs.batch is forbidden: User "system:serviceaccount:example:gitlab-example" cannot list resource "jobs" in API group "batch" in the namespace "kube-system"
Error from server (Forbidden): cronjobs.batch is forbidden: User "system:serviceaccount:example:gitlab-example" cannot list resource "cronjobs" in API group "batch" in the namespace "kube-system"

Integration Gitlab : stocker le kubeconfig

Gitlab permet de stocker des variables. Dans le cas d’un fichier kubeconfig, on va vouloir ne jamais afficher son contenu dans les logs ou autre. Pour cela il est possible de masquer vos variables en respectant quelques contraintes et notamment que la valeur de la variable tienne sur une seule ligne.

Nous allons donc encoder le fichier en base64 et rajouter un argument pour que tout soit sur une seule ligne (et non pas sur plusieurs lignes par défaut):

# create a one line base64 version of kubeconfig file
cat kubeconfig-gitlab-example.yml | base64 -w 0

Copier le contenu obtenu dans une variable que nous appelerons KUBECONFIG et dont on cochera bien la case “Mask variable”. Une fois la variable sauvée, vous avez ceci :

Intégration Gitlab : passer la référence de l’image au job de déploiement

Soit le fichier .gitlab-ci.yml suivant:

---
stages:
  - publish
  - image
  - deploy

publish:
  image:  $CI_REGISTRY/nsteinmetz/hugo:latest
  artifacts:
    paths:
      - public
    expire_in: 1 day
  only:
    - master
    - web
  script:
    - hugo
  stage: publish
  tags:
    - go

docker:
  stage: image
  image: docker:stable
  services:
  - docker:dind
  variables:
    DOCKER_HOST: tcp://docker:2375
    DOCKER_DRIVER: overlay2
    RELEASE_IMAGE: $CI_REGISTRY_IMAGE:$CI_COMMIT_SHORT_SHA-$CI_PIPELINE_ID-$CI_JOB_ID
  before_script:
    - docker login -u gitlab-ci-token -p $CI_JOB_TOKEN $CI_REGISTRY
  script:
    - echo "IMAGE=${RELEASE_IMAGE}" >> docker.env
    - docker build --pull -t $RELEASE_IMAGE .
    - docker push $RELEASE_IMAGE
  when: on_success
  tags:
    - go
  artifacts:
    reports:
      dotenv: docker.env

kube:
  stage: deploy
  script:
    - echo $KUBECONFIG | base64 --decode > kubeconfig
    - export KUBECONFIG=`pwd`/kubeconfig
    - sed -i -e "s|IMAGE|${IMAGE}|g" deployment.yml
    - kubectl apply -f deployment.yml
  needs:
    - job: docker
      artifacts: true
  when: on_success
  tags:
    - shell

Petite explication rapide :

• l’étape publish va générer la version html du site et la stocker sous la forme d’un artefact qui sera passé aux jobs suivants,
• l’étape docker va créer l’image en mettant l’artefact du job précédent dans un conteneur nginx et le publier dans la registry gitlab avec le nom suivant gitlab.registry/group/project:<short commit>-<pipeline id>-<job id>
• l’étape kube va récupérer le contenu de la variable KUBECONFIG, le décoder et créer un fichier kubeconfig. On initialise la variable d’environnement KUBECONFIG pour que kubectl puisse l’utiliser. On met à jour la référence de l’image docker obtenue précédemment dans le fichier deployment.yml qui sert de modèle de déploiement. On applique le fichier obtenu sur le cluster kubernetes pour mettre à jour le déploiement.

Le point d’attention ici est que le passage de la variable RELEASE_IMAGE se fait via un dotenv qui est créé sous la forme d’un artefact à l’étape docker et est donc disponible à l’étape kube. Cela devrait être automatique mais j’ai ajouté une dépendance explicite via la directive needs. Lors de l’étape kube, le contenu du fichier docker.env est disponible sous la forme de variables d’environnement. On peut alors faire la substitution de notre placeholder par la valeur voulue dans deployment.yml.

Tout ce mécanisme est expliqué dnas la doc des variables gitlab et sur les variables d’environnement héritées. Attention, il vous faut Gitlab 13.0+ pour avoir cette fonctionnalité et en plus, il faut préalablement activer ce feature flag.

sudo gitlab-rails console
Feature.enable(:ci_dependency_variables)

En conclusion, nous avons vu comment :

• Créer un compte de service (Service Account) sous kubernetes avec un rôle d’administrateur de namespace,
• Stocker le fichier kubeconfig utilisant notre service account dans Gitlab sous la forme d’une variable masquée,
• Passer une référence d’un job à un autre via les dotenv au niveau du job amont et les variables d’environnement au niveau du job en aval,
• Récupérer le contenu de la variable kubeconfig pour créer une variable d’environnement et être en mesure d’utiliser kubectl.

Ainsi, toute mise à jour de master conduira à une mise à jour du déploiement associé au sein du cluster kubernetes et ne nécessitera plus d’interventions manuelles comme précédemment. Avec un service account lié à un namespace, on évite aussi de s’exposer inutilement en cas de fuite des identifiants.

Le mois prochain, dans le cadre d’InfluxDays London, j’aurai le plaisir de présenter un talk sur le passage d’un monitoring Bare Metal vers un monitoring dans un monde Kubernetes avec Telegraf et InfluxDB.

Cloud

• Terraform v0.13.0 beta program : Terraform 0.13 (beta) devrait supporter au niveau des modules depends_on, count et for_each. Cela devrait éviter des dépendances parfois cryptiques.
• Deploy Any Resource With The New Kubernetes Provider for HashiCorp Terraform : la prochaine version du provider kubernetes de terraform permettra de déployer n’importe quelle ressource. Pratique ! Il vous faudra un cluster kubernetes 1.17+ pour utliser la fonctionnalité “Server Side Apply”.
• OVH : Utilisation de l’API OpenStack : Tutoriel pour le déploiement d’un wordpress sur un cluser k3s chez OVH en utilisant l’API OpenStack ; le reste du blog La Grotte du Barbu fournit plein de ressources sur kubernetes, traefik, docker, etc.

Container & orchestration

• How To Install Docker On Fedora 32 Or 31 (And Alternatives) : Même si l’utilisation de podman est recommandée en lieu et place de docke-ce depuis Fedora 31, il peut être nécessaire de vouloir utiliser docker-ce sous Fedora. Avec Fedora 32, il faut en plus des cgroups v1 à activer, il y a une règle firewall à ajouter pour que vos conteneurs aient accès au réseau / à internet.
• Harbor 2.0 : Version 2.0 de la registry Harbor qui permet d’héberger aussi des charts Helm. Pour la partie scan de vulnérabilités, le produit Clair de Quay a été remplacé par Aqua Trivy
• Announcing Maesh 1.2 : la solution de Service Mesh de Containous basée sur Traefik sort en 1.2 ; elle se base sur Traefik 2.2 et apporte donc le support de l’UDP au niveau reverse proxy. Cette version permet aussi des améliorations au niveau ACL, gestion de la configuration et gestion des middlewares par service.
• Introduction to Percona Kubernetes Operator for Percona XtraDB Cluster
• Cert-manager v0.15 and beyond
• CDK for Kubernetes : AWS vient de sortir un “Cloud Development Kit” permettant de manipuler et déployer des ressources kubernetes en python, typescript ou javascript.

DevOps

• DevOps : Discovering, Learning and Sharing (code source) : Guilhem vient de publier sa formation de culture DevOps ; à consulter !
• Radio DevOps : un podcast qui s’améliore d’épisode en épisode et plutôt adressé à des débutants dans le monde du DevOps.

IoT

• Raspberry Pi 4 USB mass storage beta (beta means it not ready yet, and not officially released!) : Le Raspberry Pi 4 va pouvoir démarrer sur un périphérique USB (clé USB, disque SSD, etc) avec l’arrivée du prochain firmware. La nécessité de la SDCard va disparaitre.

Time Series

• A multi-node, elastic, petabyte scale, time-series database on Postgres for free (and more ways we are investing in our community) : Timescale annonce que sa version cluster de TimescaleDB sera gratuite (sous licence Timescale, source code available mais pas le droit de faire un produit SaaS avec). La version monoserveur reste sous licence Apache 2.
• Grafana v7.0 released: New plugin architecture, visualizations, transformations, native trace support, and more : A l’occasion de la GrafanaCon 2020, Grafana Labs a sorti notamment Grafana 7.0 avec des tonnes d’amélioration. Il va falloir un peu de temps pour bien apprécier tout cela.
• GrafanaCon 2020 : la conférence annuelle de Grafana s’est tenue tout le mois de Mai, les vidéos sont accessibles sur la page de chaque talk après avoir saisi son email. Je n’ai malheureusement pas encore eu le temps de les visionner. Cortex 1.1 et Loki 1.5 y ont notamment été annoncés.

Code et Outillage

• 18 GitLab features are moving to open source : Gitlab va rendre disponible dans sa version Open Source 18 fonctionnalités de sa version payante. C’est un peu la lutte avec Github et ses Github Actions ou ses dernières évolutions tarifaires.

Container & orchestration

• Announcing the Compose Specification : Docker Inc vient de lancer une spécificiation officielle autour de Compose (celle derrière les docker-compose.yml) pour la rendre plus “cloud native” et plus générique avec une extension au provider cloud d’une part et d’autre part à des solutions comme kubernetes ou Amazone ECS par ex.
• Announcing Traefik 2.2, ainsi que la version Entreprise TraefikEE 2.1 basée dessus : on notera le retour du support des annotations pour gérer les Ingress, le support de l’UDP (en plus de HTTP et TCP), le support d’Elastic APM, le support des stores KV (Consul, Etcd, Redis, etc) et le Dark Mode.
• Scaleway Kubernetes Kapsule : l’offre managée kubernetes de Scaleway est disponible. Dommage que les CPU des profils de machine DEV* soient surprovisionnés et qu’il faille envisager des profils GP* pour avoir des performances correctes. L’offre est du coup moins compétitive en termes de prix pour des petits clusters.
• Kubernetes 1.18 : Fit & Finish : une version de consolidation
• How to detect outdated Kubernetes APIs : présentation de Deprek8 et de Conftest pour vous permettre d’évaluer les ressources kubernetes pour lesquelles vous n’êtes pas à jour au niveau des API.
• Helm 3.2.0 avec un correctif de sécurité sur les versions 3.0.x et 3.1.x et d’autres améliorations (comme le retour de certaines fonctionnalités non encore migrées depuis la 2.x)
• Cortex v1.0 released: The highly scalable, fast Prometheus implementation is generally available for production use : la solution de monitoring distribuée et avec un stockage de long terme basée sur Prometheus arrive en version 1.0. C’est l’occasion de se repencher sur son architecture et son fonctionnement.
• Build your very own self-hosting platform with Raspberry Pi and Kubernetes : une série d’articles pour déployer un cluster kubernetes sur vos raspberrypi avec la distributions k3s et y déployer différentes applications.
• Rook v1.3: Storage Operator Improvements : si vous n’êtes pas dans un environnement cloud, il y a de fortes chances pour que vous utilisiez Rook. La version 1.3 vient de sortir et apporte son lot d’améliorations.
• Sidecar container lifecycle changes in Kubernetes 1.18 : dans la version 1.19, le cycle de vie des sidecars dans kubernetes sera améliorée. Ainsi, ils démarreront avant le conteneur principal et s’arrêteront après. Le billet revient sur les problèmes existant et comment ce nouveau cycle de vie va améliorer la situation.

(Big) Data

• Confluent Raises $250M and Kicks Off Project Metamorphosis : Confluent, la soéciété éditrice de la Confluent Platform et d’Apache Kafka, vient de lever 250 millions de dollars et annonce le projet Metamorphosis et prévoit des annonces tous les mois sur Apache Kafka, Confluent Platform et ce projet à compter du mois de Mai. On en reparlera très certainement sur BigData Hebdo.
• Cassandra: The Definitive Guide, 3rd Edition : nouvelle édition de l’ouvrage de référence sur Cassandra, mis à jour notamment pour Cassandra 4.0 (version à venir)
• Announcing Kafka-on-Pulsar: bring native Kafka protocol support to Apache Pulsar : On en parle dans le prochain épisode de BigData Hebdo, mais Pulsar est une plateforme vraiment intéressante (Pulsar 101 en français ou en anglais) et les équipes d’OVHCloud viennent de publier un connecteur qui permet d’utliser l’API Kafka mais que les messages soient stockés dans Pulsar. Il existe aussi une vidéo sur Kafka on Pulsar et un article sur le blog d’OVHCloud.

Time Series

• Release Announcement: Telegraf 1.14.0 : 9 nouveaux inputs, 3 nouveaux processors et 1 nouvel output warp10 sont au programme de cette version. Les versions 1.14.1 et 1.14.2 sont sorties également avec quelques corrections.
• Release Announcement: InfluxDB 1.8.0 with Long-Awaited Features : la branche 1.x d’InfluxDB se voit donc dotée d’une version récente de flux qui se veut “production ready” et les endpoints d’InfluxDB 2.x sont aussi disponibles. Ce qui permet d’utiliser les nouveaux clients officiels InfluxDB prévus pour la 2.x d’une part et de faire des requêtes en Flux d’autre part.
• Release Announcement: InfluxDB 2.0.0 Beta 9 : mise à jour de Flux, autocomplétion flux dans l’éditeur de requêtes et amélioration de la CLI.
• InfluxDB Templates: Easily Share Your Monitoring Expertise : le billet a pour intérêt de présenter des bonnes pratiques sur la réalisation de templates InfluxDB. Pour rappel, les templates InfluxDB sont des “ressources” que l’on peut déclarer, exporter et importer dans une instance InfluxDB 2.x. Cela concerne des variables, labels, tasks, dashboards, alertes, etc.
• April 2020: Warp 10 release 2.5.0 : La version 2.5 de Warp10 apporte notamment un Accelerator c’est à dire un cache en mémoire pour les versions standalones. D’autres corrections et améliorations font également partie de cette release.
• WarpScript ❤️ Kafka Streams : si vous utiliser Kafka Streams et que vous voulez utiliser Warpscript pour consommer, processer et envoyer des données vers Kafka, c’est possible.
• Forecasting : Microsoft publie des exemples et des bonnes pratiques autour de la prévision à base de séries temporelles. Il y a des exemples en Python / R et quelques exemples avec Azure-ML.
• TimescaleDB 1.7: fast continuous aggregates with real-time views, PostgreSQL 12 support, and more Community features : Nouvelle version de TimeScaleDB apportant la compatibilité avec Postgresql 12.x, des aggrégats en temps réel et des fonctionnalités de gestion de données (réordonnancement et rétention) de la version Entreprise sont maintenant disponibles dans la version Community.

Web

• jQuery 3.5.0 Released! : une faille XSS a été identifiée sur jQuery.htmlFilter pour toutes les versions inférieures à 3.5.0 ; il est vivement encouragé de mettre à jour vos sites. Pour le reste, je vous renvoie à la lecture de l’article.

N’ayant pas (encore) d’imprimante 3D pour faire des protections ou à prêter à d’autres projets et souhaitant préserver ma trésorerie personnelle, je me suis posé la question de savoir si ma société pouvait contribuer à ces efforts dans la luttre contre le Covid19. Tout comme je considère que ma société doit être pérenne et assurer mes revenus, elle s’inscrit dans une société et doit y contribuer dans la mesure de ses moyens.

Connaissant différentes personnes travaillant sur le projet MakAir ; il y a eu cet appel au don (Via). C’est notamment ce qui a suscité mon questionnement, libre à vous de soutenir le projet de votre choix.

Je me suis donc tourné vers mon expert-comptable pour savoir ce qu’il était possible de faire. Une entreprise peut faire un don et le montant du don ouvrant droit à un crédit d’impôt est plafonné à 5/1000 de son chiffre d’affaires.

Dans mon cas d’espèce, cela donne un montant de 750€ ; soit la facturation d’une journée de travail environ.

Pour être complet, et même si ce n’est pas ma motivation première, d’un point de vue fiscal, il est plus intéressant de faire le versement à titre personnel, car la déduction sur l’impôt sera de 66% (plafonné à 20% du revenu imposable) alors que pour l’entreprise, c’est 60%.

Si votre société se porte raisonnablement bien en ces temps incertains et que vous ne pouvez pas contribuer directement, il est possible pour vous de participer à cet effort au travers du don notamment. Il n’est pas question de mettre votre entreprise ou vous même en difficulté, mais si vous avez l’opportunité de soutenir des projets, ce sera une contribution à l’édifice. Le don n’est pas la seule forme possible d’engagement, mon cas est juste l’occasion de vous faire réfléchir sur le sujet.

Sur ce, prenez soin de vous et de vos proches.