I suggest you...

Support for Kubernetes

The new Docker features debuting in recent versions of Octopus are really promising, and I'm excited by the Docker Compose RFC published late last year.

Kubernetes is becoming increasingly popular as the production deployment environment of choice for containerised applications. It offers functionality very similar to Azure Service Fabric, in terms of auto-scaling and self-healing of services and applications, but is based around container images rather than zip files.

442 votes
Sign in
Sign in with: facebook google
Signed in as (Sign out)
You have left! (?) (thinking…)
Alastair Smith shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →


Sign in
Sign in with: facebook google
Signed in as (Sign out)
  • Aaron Roydhouse commented  ·   ·  Flag as inappropriate

    Opinionated view incoming :-)

    This is great - no fantastic - you are thinking about Kubernetes. But I think your Kubernetes strategy should be to integrate support for a helm client and chart repositories, and use the power of Octopus to push variables and secrets into helm charts.

    I looked at the you github concept page, and there is no way you're going to make the form match the expressiveness of yaml manifests that Kubernetes provides, let alone the expressiveness of yaml+go templates. It is a lot of work and it won't get used because there will always be 2% that is missing or not up to date with the fast-moving k8s versions, that means users can't do what they want.

    And few people still use raw yaml manifests anyway. They either generate the manifests from e.g. terraform or most often they create or re-use helm charts.

    I think competitively you want Octopus to be the best darn way to inject variables and secrets and automate helm deployments.

    You introduced docker support just when docker was hitting the skids, if you go for for
    k8s manifest forms now you're again targeting the tail end of the zeitgeist.

    We already to use Octopus for Kubernetes for about a year, we use Octopus action steps to pull helm charts from git or helm repos, inject values, and run the helm client on an ssh target. Works great. But would be better if the helm client was integrated with Octopus and Octopus understood helm charts and value files. The Kubernetes support you're planning, we'll never use, we moved on from that era 18 months ago.

  • Stanislav Hordiyenko commented  ·   ·  Flag as inappropriate

    Meanwhile, I set up linux box with Calamari, installed gcloud, kubectl, docker. Added this box to all environments and configured a project to do deployment to the Kubernetes cluster. Use namespaces to separate environments. Works like a charm.

  • Jim commented  ·   ·  Flag as inappropriate

    Looking forward to seeing and using this feature. Expect this to be a key part in our CD processes.

  • Garry commented  ·   ·  Flag as inappropriate

    Great to see this getting on the roadmap.

    As for the lack of parameters files and the variable substitution, I'd encourage using Helm charts (and their values.yaml) as a good design pattern.

Feedback and Knowledge Base