I am looking to deploy multiple containers into Azure something like:
Gateway / Proxy such as Traefik
Web service 1
Web service 2
Web service 3
Fake Database such postgreSQL
I have seen the example Deploy a app service container but this is a very simple container with a single service. I am looking for a more complex solution where I am deploying 10+ containers. I will probably use Azure Gateway in front of the container proxy, but would like to keep things as near to my Dev and test environments.
The workflow i am trying to achieve is locally deployments for DEV / TEST onto dedicated hosts running docker which is working without any issues. Then finally deploy into Azure for production using Octopus. I am currently using a private docker hub repository and would like to continue using this if possible. If this is not feasible I could use my CI to push the containers into an Azure registry but would like to avoid if possible. I would like a single source of truth for my containers (docker hub).
Any guides or guidance would be greatly appreciated.
Is there a better method start the service from Octopus that checks it exist and creates if required? I need to be able to let the proxy / gateway service communicate to the others, and why I exposing each of the service in the AKS internally?
Also what is the best way to deploy a new storage and mount the volume to a container?
Just jumping in for Finn as he won’t be online for a while.
Thanks for letting us know and you’re very welcome!
To answer your questions:
guessing deploy raw yaml - Correct, you’ll use Raw YAML in this case.
what happens if for example the storage already exists? - It will fail saying it already exists. Our step just uses kubectl commands and is a wrapper for them so any testing you want to do outside of Octopus with kubectl would translate to the same behavior within Octopus.
Please let me know if that helps or if you have any other questions!
If this is the case that it fails. What would be your suggestion or the best to handle if it already exist from within octopus. Is the best way to ignore the step if it fails and continue to the run the rest of the steps.
I had a chat with a colleague and we both agree that the best way to do this would be to create a step before it that checks if the storage exists, and based on the result, create an output variable that determines whether the “create persistant storage” step (You will need to separate that yaml out into its own step if you haven’t) runs.
Here is an example of something similar where our solutions team set up steps to check for existing Octopus nodes and deletes them if they exist: Octopus Deploy
Please let me know if that helps or if you have any questions!
We had a quick chat and we think you can achieve this in a couple of ways. You would run either an Azure CLI step or a Kubectl step within Octopus and reference the package you want to upload to the persistent storage/pods. Then you would either use azcopy or kubectl cp(depending on the path you go down) to get those files to where you need them.
Sorry I don’t have too much more information than that, but hopefully that helps.
Please let me know if you get it going, you never know if someone will find your post and need the answer in the future!