akuity / mta Goto Github PK

License: Apache License 2.0

Go 100.00%

mta's Introduction

mta (Migrate to Argo CD)

The mta cli will export Flux components to Argo CD consumable CRs. This can be used in order to help migrating from Flux to Argo CD. This is in the "proof of concept" phase and we make no guarantees.

We love feedback! Come join us at our Akuity Discord Community!

Installation

Install the mta binary from the releases page in your $PATH.

There is shell completion for convenience.

NOTE it's probably zsh on a Mac

mta completion bash

Quickstart

Here's a video which explains how to use 'mta' to export Flux components to Argo CD consumable CRs.

Below are some examples

Manual Migration

NOTE: See the Flux Documentation for more information about Flux.

After downloading the binary, you can scan your system for HelmReleases and Kustomizations. Example:

$ mta scan 
┌───────────────┬─────────────┬─────────────┬─────────────────────────────────────────────────────────────────┐
│ KIND          │ NAME        │ NAMESPACE   │ STATUS                                                          │
├───────────────┼─────────────┼─────────────┼─────────────────────────────────────────────────────────────────┤
│ HelmRelease   │ podinfo     │ flux-system │ Release reconciliation succeeded                                │
│ HelmRelease   │ sample      │ flux-system │ Release reconciliation succeeded                                │
├───────────────┼─────────────┼─────────────┼─────────────────────────────────────────────────────────────────┤
│ Kustomization │ flux-system │ flux-system │ Applied revision: main/f35c47113103d67b20859a2301fa5c88a8f7c6c9 │
└───────────────┴─────────────┴─────────────┴─────────────────────────────────────────────────────────────────┘

You can then, migrate them over; for example to migrate the HelmRelease called sample (in my above example), you can do:

$ mta helmrelease --name sample

You'll see the Argo CD Application that will be created:

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: sample
  namespace: argocd
spec:
  destination:
    namespace: quarkus
    server: https://kubernetes.default.svc
  project: default
  source:
    chart: quarkus
    helm:
      values: |
        build:
          enabled: false
        deploy:
          route:
            enabled: false
        image:
          name: quay.io/ablock/gitops-helm-quarkus
    repoURL: https://redhat-developer.github.io/redhat-helm-charts
    targetRevision: 0.0.3
  syncPolicy:
    automated:
      prune: true
      selfHeal: true
    syncOptions:
    - CreateNamespace=true
    - Validate=false

You can pipe this into kubectl apply or you can have mta do it for you

NOTE You'll have to install Argo CD before running this command

$ mta helmrelease --name sample --confirm-migrate

The same can be done for Kustomizations, example:

NOTE Kustomizations, because of the nature of how they are setup, are migrated via an ApplicationSet

$ mta kustomization --name flux-system --confirm-migrate

By default, the ApplicationSet created from the Kustomiation will exclude the flux-system directory. You can exclude other directories that have Flux specific Kubernetes objects by passing the --exclude-dirs option.

$ mta kustomization --name flux-system --exclude-dirs flux-system-extras --confirm-migrate

NOTE To exclude more directories, you an pass a comma separated list to --exclude-dirs. Example: --exclude-dirs foo,bar,bazz. You can also pass --exclude-dirs to the scan command as well.

Auto Migration

You can have the scan subcommand automatically migrate everything for you

‼️ NOTE This option also deletes Flux from the system. Use with caution

$ mta scan --auto-migrate

mta's People

Contributors

Stargazers

Watchers

Forkers

matesousa paragbhingre

mta's Issues

[BUG] Double resources with HelmReleases

When you migrate over a HelmRelease, it will "double" everything. Example using podinfo helmchart after migration

$ Kubectl get all -n podinfo-system
NAME                                          READY   STATUS    RESTARTS   AGE
pod/podinfo-758bbb57d6-c8pzv                  1/1     Running   0          14m
pod/podinfo-758bbb57d6-crqt4                  1/1     Running   0          14m
pod/podinfo-system-podinfo-55879b6fd8-qx8xt   1/1     Running   0          15m
pod/podinfo-system-podinfo-55879b6fd8-s4tmn   1/1     Running   0          15m

NAME                             TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)             AGE
service/podinfo                  ClusterIP   10.96.189.154   <none>        9898/TCP,9999/TCP   14m
service/podinfo-system-podinfo   ClusterIP   10.96.190.92    <none>        9898/TCP,9999/TCP   15m

NAME                                     READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/podinfo                  2/2     2            2           14m
deployment.apps/podinfo-system-podinfo   2/2     2            2           15m

NAME                                                DESIRED   CURRENT   READY   AGE
replicaset.apps/podinfo-758bbb57d6                  2         2         2       14m
replicaset.apps/podinfo-system-podinfo-55879b6fd8   2         2         2       15m

Notice how there is podinfo- and podinfo-system-podinfo-. A workaround (potentially dangerous) is to delete the resources by hand and sync the application.

This worked on my test system:

$ kubectl delete all --all -n podinfo-system && argocd app sync podinfo

$ kubectl get all -n podinfo-system
NAME                           READY   STATUS    RESTARTS   AGE
pod/podinfo-758bbb57d6-dlclg   1/1     Running   0          15s
pod/podinfo-758bbb57d6-l4bjr   1/1     Running   0          15s

NAME              TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)             AGE
service/podinfo   ClusterIP   10.96.170.133   <none>        9898/TCP,9999/TCP   20s

NAME                      READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/podinfo   2/2     2            2           15s

NAME                                 DESIRED   CURRENT   READY   AGE
replicaset.apps/podinfo-758bbb57d6   2         2         2       15s

mta should account for this somehow.

Add destination kubeconfig option

In the case where Argo CD is installed on another cluster, there's no way to specify that destination cluster. It would be nice to add a global flag --destination-kubeconfig for the end user to provide that destination cluster's Kubeconfig.

Example:

mta scan --auto-migrate --confirm --destination-kubeconfig /path/to/argocd/kube.config

Current workaround is to migrate components using kubectl

Example:

mta helmrelease --name sample | kubectl apply --kubeconfig  /path/to/argocd/kube.config -f -

[RFE] Prompt user for auto migration

The --auto-migrate option for the scan subcommand migrates everything and deletes Flux for you, without warning. The user should be prompted. There should also be a --confirm option added to do it without prompting.

This should prompt the user

$ mta scan --auto-migrate

This should auto migrate without prompting

$ mta scan --auto-migrate --confirm

Add directory exclusions

It would be nice if we add the ability to exclude directories in the kustomization. Right now flux-system is automatically excluded. But sometimes Flux specific objects are put in other directories (for example, Kingdon always says to put extra things in flux-system-extras).

It would be cool if you could do --exclude <dir name>,<dir name>,<dir name> or add it to a config file.

Migrate via multiple applications instead of applicationset

Right now, migration of kustomizations happens via ApplicationSet. It would be nice to add an option to migrate via multiple applications.

[Bug] CRDs Hang around

CRDs seem to hang around after migration. Example from my test system

$ mta scan
┌───────────────┬─────────────┬─────────────┬─────────────────────────────────────────────────────────────────┐
│ KIND          │ NAME        │ NAMESPACE   │ STATUS                                                          │
├───────────────┼─────────────┼─────────────┼─────────────────────────────────────────────────────────────────┤
│ Kustomization │ flux-system │ flux-system │ Applied revision: main/f35c47113103d67b20859a2301fa5c88a8f7c6c9 │
└───────────────┴─────────────┴─────────────┴─────────────────────────────────────────────────────────────────┘

But the migration has already happened

$ kubectl get pods -A
NAMESPACE            NAME                                               READY   STATUS    RESTARTS   AGE
argocd               argocd-application-controller-0                    1/1     Running   0          28m
argocd               argocd-applicationset-controller-695d5488d-sktdf   1/1     Running   0          28m
argocd               argocd-dex-server-6896f577ff-mg9fm                 1/1     Running   0          28m
argocd               argocd-notifications-controller-6774bf5859-kvv26   1/1     Running   0          28m
argocd               argocd-redis-79c755c747-wwvdm                      1/1     Running   0          28m
argocd               argocd-repo-server-7bbc9bcf85-fw828                1/1     Running   0          28m
argocd               argocd-server-8455bf6676-mdhlm                     1/1     Running   0          28m
bgd                  bgd-674c98bf9c-frpsp                               1/1     Running   0          29m
kube-system          coredns-565d847f94-9t7nf                           1/1     Running   0          29m
kube-system          coredns-565d847f94-csbvn                           1/1     Running   0          29m
kube-system          etcd-kind-control-plane                            1/1     Running   0          29m
kube-system          kindnet-54rmt                                      1/1     Running   0          29m
kube-system          kube-apiserver-kind-control-plane                  1/1     Running   0          29m
kube-system          kube-controller-manager-kind-control-plane         1/1     Running   0          29m
kube-system          kube-proxy-cq5dq                                   1/1     Running   0          29m
kube-system          kube-scheduler-kind-control-plane                  1/1     Running   0          29m
local-path-storage   local-path-provisioner-684f458cdd-9jxr2            1/1     Running   0          29m
podinfo-system       podinfo-758bbb57d6-dlclg                           1/1     Running   0          9m24s
podinfo-system       podinfo-758bbb57d6-l4bjr                           1/1     Running   0          9m24s
quarkus              sample-845fdbd9c-5bt26                             1/1     Running   0          10m
welcome-php          welcome-php-6c665bfb77-wjs29                       1/1     Running   0          29m

Looks like finalizers?

$ kubectl get ns flux-system
NAME          STATUS        AGE
flux-system   Terminating   30m

The FluxCleanUp function could be "smarter"

Kustomization migration assumes git creds is needed

Given the following GitRepository and Kustomization...

---
apiVersion: source.toolkit.fluxcd.io/v1
kind: GitRepository
metadata:
  name: gitops-examples
  namespace: flux-system
spec:
  interval: 1m0s
  ref:
    branch: main
  url: https://github.com/christianh814/gitops-examples
---
apiVersion: kustomize.toolkit.fluxcd.io/v1
kind: Kustomization
metadata:
  name: welcome-app
  namespace: flux-system
spec:
  interval: 10m0s
  path: ./welcome-k8s/overlays/default
  prune: true
  sourceRef:
    kind: GitRepository
    name: gitops-examples

The following command will fail

$ mta kustomization --name welcome-app
FATA[0000] gitrepositories.source.toolkit.fluxcd.io "welcome-app" not found

This is because mta currently assumes that all repos require authentication

This should be changed to check to see if the Kustomization is using a public repo.

Set Deletion Propagation for HelmReleases

When migrating a Helm release, .spec.uninstall.deletionPropagation needs to be set to orphan so there isn't an adverse effect when removing the HelmRelease Flux object. See the FOLLOWING DOCUMENTATION