My organization is planning to migrate our entire CI/CD infrastructure from an on-premise server to GCP. We have a lot of legacy plugins and custom shell scripts. Should we use the Jenkins GKE setup or just mirror our current VM setup using Google Compute Engine? I'm concerned about plugin compatibility and the migration of our build history and artifacts.
3 answers
Use the "Configuration as Code" (JCasC) plugin to rebuild your Jenkins instance on GCP. It makes the migration much cleaner and reproducible.
If you want to modernize, GKE is the way to go, but if you have a lot of "legacy" dependencies, a "Lift and Shift" to Google Compute Engine (GCE) is safer and faster. You can use the Google Cloud Storage (GCS) plugin to offload your build artifacts, which solves the storage scaling issue. For build history, you can simply rsync your JENKINS_HOME directory to the new persistent disk on GCE. Once you are stable on GCE, you can slowly containerize your build environments and eventually migrate those agents to GKE without moving the entire controller at once.
Are you worried about the networking latency between your on-premise bitbucket and the new Jenkins instance on GCP during the transition?
Latency is definitely a concern, Richard. We are setting up a Cloud VPN to ensure a secure and fast connection. To mitigate issues, we are moving our Git repositories to Google Cloud Source Repositories first. This minimizes the cross-environment traffic. Mary's suggestion of a staged migration is what we've decided on; we'll start with the agents on GCE and keep the controller on-premise for a few weeks to ensure all our custom hooks still work before making the final jump.
Susan is right. JCasC is essential for cloud migrations to ensure your configuration isn't lost and can be easily updated in the new environment.