• Menu

    ArgoCD integration

    Use the following steps to integrate ArgoCD with BundleBee.

    Important
    		 this page assumes you are already familiar with ArgoCD, if it is not the case refer to ArgoCD documentation please.

    Define BundleBee as a plugin

    The goal is to be able to identify a repository with a manifest.json as a BundleBee repository and use BundleBee to convert the repository to JSON files ArgoCD will deploy as descriptors.

    The steps to integrate with bundlebee are the following ones:

    1. Create a ConfigManagementPlugin,

    2. Configure your application to scan for manifest.json.

    Create the BundleBee ConfigManagementPlugin

    First define this descriptor:

    bundlebee.argocd-plugin.yaml
    apiVersion: argoproj.io/v1alpha1
kind: ConfigManagementPlugin
metadata:
  name: bundlebee-plugin
spec:
  version: v1.0
  init:
    # if you use any kind of secret management, it can be neat to run a command there to decipher the secrets and prepare generate command
    command: [sh]
    args: [-c, 'echo "BundleBee plugin"']
  generate:
    command: [ "/opt/yupiik/bundlebee/bin/bundlebee.sh" ]
  discover:
    find:
      glob: "**/bundlebee/manifest.json"
  parameters:
    dynamic:
      command: [ "/opt/yupiik/bundlebee/bin/bundlebee.placeholders.sh" ]
    preserveFileMode: false
    Important
    		 this is NOT a Kubernetes descriptor so don’t install it wit kubectl or BundleBee. Also note that the command used there only work for BundleBee >= 1.0.25, for versions before use process command to dump the descriptors and then a small script to cat them for ArgoCD.

    Now create a plugin docker image:

    Dockerfile
    FROM ossyupiik/java:17.0.9.1
RUN mkdir -p /opt/yupiik/bundlebee/lib /opt/yupiik/bundlebee/bin && \
    wget https://repo.maven.apache.org/maven2/io/yupiik/bundlebee-core/1.0.24/bundlebee-core-1.0.24-fat.jar -O /opt/yupiik/bundlebee/lib/bundlebee.jar (1)
COPY ./bundlebee.argocd-plugin.yaml /home/argocd/cmp-server/config/plugin.yaml (2)
COPY ./bundlebee.plugin.sh /opt/yupiik/bundlebee/bin/bundlebee.sh
RUN chmod +x /opt/yupiik/bundlebee/bin/*.sh && chown 999:0 -R /opt/yupiik/
USER 999
ENTRYPOINT ["/opt/yupiik/bundlebee/bin/bundlebee.sh"]

    1. Ensure to adjust the version you want to use at your needs,

    2. Ensure to add the plugin configuration we just created locally in previous step (target location is required by the entry point).

    Tip
    		 you can also use the native version of BundleBee but this requires some more knowledge about the Java native dependencies (apk add --no-cache zlib libstdc++ gcompat for alpine for example).

    The launching script will be something like:

    #! /bin/sh

java -Dio.yupiik.bundlebee.level=WARNING -jar \
    /opt/yupiik/bundlebee/lib/bundlebee.jar process \
    --injectTimestamp false --injectBundleBeeMetadata false \
    --output stdout \
    --bundlebee-kube-namespace "${ARGOCD_APP_NAMESPACE}" \
    --from "$ARGOCD_APP_SOURCE_PATH" --manifest "${ARGOCD_APP_SOURCE_PATH}/bundlebee/manifest.json" --alveolus "$ARGOCD_APP_NAME"

    And the discovery script will be something like:

    #! /bin/sh

java -Dio.yupiik.bundlebee.level=WARNING -jar \
    /opt/yupiik/bundlebee/lib/bundlebee.jar placeholder-extract \
    --outputType ARGOCD \
    --bundlebee-kube-namespace "${ARGOCD_APP_NAMESPACE}" \
    --from "$ARGOCD_APP_SOURCE_PATH" --manifest "${ARGOCD_APP_SOURCE_PATH}/bundlebee/manifest.json" --alveolus "$ARGOCD_APP_NAME"
    Important
    		 the placeholder discovery and descriptor templating assume ArgoCD application name matches the alveolus name, you can modify the script to make it more resilient.

    Then build the image: docker build -t yupiik/argocd-bundlebee-plugin:latest ..

    Now we need to add this configuration into a sidecar of ArgoCD (CMP server). To do that, edit argocd-repo-server descriptor (we explain how to do it manually but you can do it with BundleBee): kubectl edit deploy -n argocd argocd-repo-server.

    Add the plugin container:

    containers:
... (1)
- name: bundlebee-plugin
  command: [/var/run/argocd/argocd-cmp-server]
  image: yupiik/argocd-bundlebee-plugin:latest (2)
  # if you build the image in minikube directly uncomment next line
  # imagePullPolicy: IfNotPresent
  securityContext:
    runAsNonRoot: true
    runAsUser: 999
  volumeMounts:
    - mountPath: /var/run/argocd
      name: var-files
    - mountPath: /home/argocd/cmp-server/plugins
      name: plugins

    1. Keep default container(s),

    2. Set the image you just built.

    Limitations

    The limitations of the integration is that BundleBee does not deploy any more, it is just used as a templating engine (similarly to helm integration) so ArgoCD is the deployer. The drawback of that option is you loose the deployment options (like forcing PUT to force to override a resource, the control of the merge strategy when you install a resource or the awaiting logic which is different).

    Please also note that ArgoCD:

    • Is a runtime so you must ensure it is

      • up and running,

      • has enough allocated resources (including to redeploy a new version if you use rollout),

      • monitored for upgrades when needed (security + features),

      • has enough storage for its usage (avoid a disk full for ex),

      • has a correct monitoring to ensure you don’t get into infra troubles if you host it on premise.

    • Does not come with a solution for secrets (and passwords/keys management) so you still need an option for that,

    • Does use a custom RBAC model for security which is not always trivial to set up.

    • As any software is a new thing to learn for your ops team and can compete with the idea of CI/CD (which has its own RBAC model for example),

    • Since it will store your clusters client configuration, the cluster ArgoCD is installed on must have very secured secrets (don’t use a weaky-leaky dev environment for example),

    • Similarly to the cluster, if you use some ciphering solution, ensure its storage is very well secured (can go through Kubernetes secrets if you have a specific backend - ie not the default one).

    This is why at Yupiik we tend to not use ArgoCD but prefer a plain CI/CD pipeline which is offline (does not need a constant runtime resource allocation nor infra monitoring and is self-resilient since you just need git to restore an application). Most of the time we couple it with BundleBee diff command to ensure if the cluster is synchronized or not with the git state. We combine it with a ciphering to save password/keys in git, depending the project it can be a Vault, keypass or just our (de)crypt maven goal which uses a master password for that task (similarly you can use {{bundlebee-decipher:$masterKeyPlaceholder,$cipheredValue}} placeholders, see more on how it works page). Finally, combine with minisite generator we get live documentation reporting (including potential placeholders) which makes the solution complete.

    Important
    		 it is highly recommended to work on these points before adopting ArgoCD (using BundleBee or not indeed) and to evaluate the plain CI/CD option - including installing a light CI/CD like Harness/Drone which is simpler to setup.

    Navigation