In our business of building and maintaining cloud infrastructures, there is considerable interest among our clients in building and deploying apps across multiple clouds. This idea is appealing because some clients don’t want to be tied to a single cloud, or they want to take advantage of credits provided by a different cloud provider. In reality, given the differences across different clouds, multi-cloud deployment is not simple.
Spinnaker is an open source tool from Netflix, which is often mentioned in multi-cloud discussion. If you are thinking about using Spinnaker, you have come to the right place. In this blog post, we’ll point out 6 things you should know about Spinnaker before you use it.
Spinnaker is not a complete solution
Spinnaker only handles deployment, so it will only create security groups, load balancers and images. That’s all. So, if your application needs a database, and most likely it does, you’ll still need leverage tools, like Terraform or CloudFormation, to provision the core infrastructure. For example, If you are on AWS, all the core network related resources like VPC, subnet groups has to be created outside of Spinnaker. Which leads us to the next point.
Anything you create manually must have a specific name
Spinnaker can only detect your subnets and security groups if they are called using some notation. Otherwise, you won’t be able to use them.
For Spinnaker, security groups names must have this format: <application name>-<security group name>. For example, myApp-l might be one security group. However, your subnets must have this format: <application name>.<subnet name>.<region>. For example, myApp.public.us-east-1 could be a subnet. Note one uses dashes and the other uses dots.
Also if you want to do multi AZ deployments your subnets must have the same name. For example if you want to use two different Availability Zones and have separated public and private subnets you should call them myApp.public.us-east-1 for both Availability Zones us-east-1a and us-east-1b in the public side and myApp.private.us-east-1 for both Availability Zones us-east-1a and us-east-1b in the private side.
There are no IP range rules
Spinnaker only lets you create rules for your created security groups based on other security groups. If you want a rule for a specific IP range, you must directly edit the security groups.
Spinnaker uses Packer
From the Spinnaker interface, you can bake images. However, you can only install one package from the apt; you cannot configure it in any way. If, by default, the package is configured to just listen to localhost, there is no way to change the configuration with Spinnaker.
Fortunately, you can create your own Packer projects with more complex installations, but you cannot easily upload them from Spinnaker. You will need to enter the instance running Spinnaker and upload the file directly. As a base, you can use the existing Packer files in the instance since Spinnaker sends some parameters to Packer, so the tool knows where to run the instance to build.
Spinnaker has multiple deployment strategies
Spinnaker provides different development strategies, so you can select the best for your use case. If you need something different for your deployment, the tool also lets you create new deployment strategies to enable you to accomplish exactly what you need.
Authentication can be added
By default, you can access the interface, making an SSH tunnel. There is no log; you work as an anonymous user. However, Spinnaker does not provide user authentication itself. Instead, it delegates this functionality to third parties, such as OAuth 2.0, SAML 2.0 or X.509 Certificates, so you can select who will be your identity provider.
Last thoughts
In summary, here is what we recommend. The deployment is the least of your worries if multi-cloud is really your ultimate goal because provisioning and maintaining core infrastructure require substantial effort. You are probably better off sticking with Kubernetes and Jenkins pipelines. Most likely, you already have Jenkins and Jenkins expertise in-house, and you’ll get far more flexibility if you go that route. There is a wealth of information available on how to achieve blue-green deployments and continuous delivery using Kubernetes + Jenkins.
If you are on AWS, and you don’t care about multi-cloud, we suggest using ECS and Jenkins for deployment. Here also, it’s easy to build a continuous delivery pipeline using simple Jenkins jobs.We would love to hear your feedback. Please feel free to leave questions and comments.
