Migrate from Halyard to the Operator

This guide is for both the Armory Operator and the Spinnaker Operator. Armory Continuous Deployment and Spinnaker configuration is the same except for features only in Armory Continuous Deployment. Those features are marked .

Before you begin

You need to decide if you want to overwrite the current Halyard deployment of Armory Continuous Deployment or create a test instance.

If you choose to overwrite your current instance, you need to take downtime to clean up the namespace that the Halyard-deployed Armory Continuous Deployment is in so Operator can deploy Armory Continuous Deployment without collision.

Alternately, you can use Operator to deploy Armory Continuous Deployment to a different namespace to test out the migration. You need to create a separate data store as well as separate Gate and Deck URLs for your test instance of Armory Continuous Deployment. Once you’ve verified that Operator has deployed your test configuration as you expected, decommission the Halyard-deployed instance of Armory Continuous Deployment. Change the data store config and URLs in the manifest that Operator used to deploy your test instance to match what your decommissioned instance used. Then redeploy.

The second method is preferred as it allows you to test everything before decommissioning Armory Continuous Deployment that you deployed using Halyard.

Migrate to Operator

This guide assumes you want to deploy Armory Continuous Deployment using a single SpinnakerSerivce.yml manifest file rather than Kustomize patches.

The migration process from Halyard to Operator can be completed in 7 steps:

1. Install the Operator.

2. Export configuration.

   Copy the desired profile’s content from the config file

   For example, if you want to migrate the default hal profile, use the following SpinnakerService manifest structure:

   currentDeployment: default
   deploymentConfigurations:
   - name: default
     <CONTENT>
   

   Add <CONTENT> in the spec.spinnakerConfig.config section in the SpinnakerService manifest as follows:

   spec:
     spinnakerConfig:
       config:
         <<CONTENT>>
   

   Note: config is under ~/.hal

   You can see more details in spec.spinnakerConfig.config.

3. Export Armory Continuous Deployment profiles.

   If you have configured Armory Continuous Deployment profiles, you need to migrate these profiles to the SpinnakerService manifest.

   First, identify the current profiles under ~/.hal/default/profiles.

   For each file, create an entry under spec.spinnakerConfig.profiles.

   For example, you have the following profile:

   $ ls -a ~/.hal/default/profiles | sort
   echo-local.yml
   

   Create a new entry with the name of the file without -local.yaml as follows:

   spec:
     spinnakerConfig:
       profiles:
         echo:
           <CONTENT>
   

   You can see more details in spec.spinnakerConfig.profiles.

4. Export Armory Continuous Deployment settings.

   If you configured Armory settings, you need to migrate these settings to the SpinnakerService manifest also.

   First, identify the current settings under ~/.hal/default/service-settings.

   For each file, create an entry under spec.spinnakerConfig.service-settings.

   For example, you have the following settings:

   $ ls -a ~/.hal/default/service-settings | sort
   echo.yml
   

   Create a new entry with the name of the file without .yaml as follows:

   spec:
     spinnakerConfig:
       service-settings:
         echo:
           <CONTENT>
   

   You can see more details in spec.spinnakerConfig.service-settings.

5. Export local file references.

   If you have references to local files in any part of the config, like kubeconfigFile, service account JSON files or others, you need to migrate these files to the SpinnakerService manifest.

   For each file, create an entry under spec.spinnakerConfig.files.

   For example, you have a Kubernetes account configured like this:

   kubernetes:
     enabled: true
     accounts:
     - name: prod
       requiredGroupMembership: []
       providerVersion: V2
       permissions: {}
       dockerRegistries: []
       configureImagePullSecrets: true
       cacheThreads: 1
       namespaces: []
       omitNamespaces: []
       kinds: []
       omitKinds: []
       customResources: []
       cachingPolicies: []
       oAuthScopes: []
       onlySpinnakerManaged: false
       kubeconfigFile: /home/spinnaker/.hal/secrets/kubeconfig-prod
     primaryAccount: prod
   

   The kubeconfigFile field is a reference to a physical file on the machine running Halyard. You need to create a new entry in files section like this:

   spec:
     spinnakerConfig:
       files:
         kubeconfig-prod: |
                   <CONTENT>
   

   Then replace the path in the config to match the key in the files section:

   kubernetes:
     enabled: true
     accounts:
     - name: prod
       requiredGroupMembership: []
       providerVersion: V2
       permissions: {}
       dockerRegistries: []
       configureImagePullSecrets: true
       cacheThreads: 1
       namespaces: []
       omitNamespaces: []
       kinds: []
       omitKinds: []
       customResources: []
       cachingPolicies: []
       oAuthScopes: []
       onlySpinnakerManaged: false
       kubeconfigFile: kubeconfig-prod  # File name must match "files" key
     primaryAccount: prod
   

   You can see more details in spec.spinnakerConfig.files.

6. Export Packer template files (if used).

   If you are using custom Packer templates for baking images, you need to migrate these files to the SpinnakerService manifest.

   First, identify the current templates under ~/.hal/default/profiles/rosco/packer.

   For each file, create an entry under spec.spinnakerConfig.files.

   For example, you have the following example-packer-config file:

   $ tree -v ~/.hal/default/profiles
   ├── echo-local.yml
   └── rosco
       └── packer
           └── example-packer-config.json
   
   2 directories, 2 files
   

   You need to create a new entry with the name of the file following these instructions:

   • For each file, list the folder name starting with profiles, followed by double underscores (__) and at the very end the name of the file.

   spec:
     spinnakerConfig:
       files:
         profiles__rosco__packer__example-packer-config.json: |
                   <CONTENT>
   

   You can see more details in spec.spinnakerConfig.files.

7. Validate your Armory configuration if you plan to run the Operator in cluster mode:

   kubectl -n <namespace> apply -f <spinnaker service manifest> --dry-run=server
   

   The validation service throws an error when something is wrong with your manifest.

8. Apply your SpinnakerService:

   kubectl -n <namespace> apply -f <spinnaker service>
   

Help resources

• Armory Operator and Armory Continuous Deployment: contact Armory Support or use the Spinnaker Slack #armory channel.
• Spinnaker Operator and Spinnaker: Spinnaker Slack #kubernetes-operator channel.