Is this targeted at IT or devops or developers? Also, how does this compare to https://cloudron.io ?
Microsoft and Docker team up to make packaging cloud-native applications easier
31–40 of 83 posts
Re: Microsoft and Docker team up to make packaging cloud-native applications easier
#32Earlier quoted context omitted.
As I said, we have lots of customers who need a packaging format that targets clouds APIs which in some cases don't have any containers (hence no need for Kubernetes). Functions + datastore + service bus being a good example. I know there's lots of love for Kubernetes, containers, and operators -- with me too. Still we can't and shouldn't presume the existence of Kubernetes or Kubernetes APIs to solve the problems CN…
From reading the spec though it looks like everything uses containers built from a Dockerfile: "A bundle is comprised of a bundle definition and at least one invocation image. The invocation image's job is to install zero or more components into the host environment. Such components MAY include (but are not limited to) containers, functions, VMs, IaaS and PaaS layers, and service frameworks." So, the very first step…
Right. We took a dependency on a container runtime and not on a container orchestrator.
One of the examples we show is an electron app that provides a desktop installer experience for a cloud-based distributed application. We presume a container runtime for this.
We expect CNAB to play nicely with Kubernetes lifecycle management, but taking a hard dependency on Kubernetes was not deemed advantageous to CNAB's design goals.
Re: Microsoft and Docker team up to make packaging cloud-native applications easier
#33Earlier quoted context omitted.
As I said, we have lots of customers who need a packaging format that targets clouds APIs which in some cases don't have any containers (hence no need for Kubernetes). Functions + datastore + service bus being a good example. I know there's lots of love for Kubernetes, containers, and operators -- with me too. Still we can't and shouldn't presume the existence of Kubernetes or Kubernetes APIs to solve the problems CN…
From reading the spec though it looks like everything uses containers built from a Dockerfile: "A bundle is comprised of a bundle definition and at least one invocation image. The invocation image's job is to install zero or more components into the host environment. Such components MAY include (but are not limited to) containers, functions, VMs, IaaS and PaaS layers, and service frameworks." So, the very first step…
It doesn't have to be a container. We have experimented with using VMs as the CNAB runtime as seen with the azure-vm driver in our reference implementation, duffle: https://github.com/deislabs/duffle/tree/master/drivers/azure...
Most of the examples are primarily container-based and the specification reflects that. We will definitely have to do a better job fleshing out the design with alternative invocation image types than OCI/docker. The azure-vm driver is one such (experimental) example.
Hope this helps!
Re: Microsoft and Docker team up to make packaging cloud-native applications easier
#34Gabe from Microsoft here. Happy to answer any questions. A few links to help you explore the spec and tooling: - https://cnab.io - https://duffle.sh/ - https://open.microsoft.com/2018/12/04/announcing-cnab-cloud-...
Does it work with Windows Server and Windows 10 the same way that docker does? Can it be utilized without docker?
Re: Microsoft and Docker team up to make packaging cloud-native applications easier
#35Gabe from Microsoft here. Happy to answer any questions. A few links to help you explore the spec and tooling: - https://cnab.io - https://duffle.sh/ - https://open.microsoft.com/2018/12/04/announcing-cnab-cloud-...
Thank you for being here and answering questions. Is there any way you can (internally) push to remove roadblocks for the insanity of Windows Home vs Pro for Docker/Hyper-V? I know this isn't possible in the short run but I think it prevents a lot of children from getting started with Docker.
Based on what Scott Guttrie's team has been able to accomplish, I am cautiously optimistic that this is possible if there is enough push for it from within Microsoft. Thank you once again for your support!
Re: Microsoft and Docker team up to make packaging cloud-native applications easier
#36Earlier quoted context omitted.
I see it a bit differently. To me it looks like CNAB invents a new way of describing and deploying an application that looks nothing like a Kubernetes API while Crossplane is trying to use the existing Kubernetes API tooling to interoperate with and leverage that ecosystem. Just because you are using a Kubernetes API doesn't mean you are presuming a Kubernetes cluster IMHO. The work being done with virtual kubelet[1]…
As I said, we have lots of customers who need a packaging format that targets clouds APIs which in some cases don't have any containers (hence no need for Kubernetes). Functions + datastore + service bus being a good example. I know there's lots of love for Kubernetes, containers, and operators -- with me too. Still we can't and shouldn't presume the existence of Kubernetes or Kubernetes APIs to solve the problems CN…
This doesn't come across in the press that is being made. Perhaps it is just the join messaging with Docker. The purpose of CNAB isn't clear as a generic spec as the examples are all with duffle and dockerapp. Still reading the spec though.
Re: Microsoft and Docker team up to make packaging cloud-native applications easier
#37I've been working on something similar with sugarkube[1]. It looks like it takes a different approach and aims to solve more of the toolchain. I'd be interested in feedback if anyone has the time... [1] https://github.com/sugarkube/sugarkube
Can you elaborate? It's not completely clear from the README.
Re: Microsoft and Docker team up to make packaging cloud-native applications easier
#38Earlier quoted context omitted.
Absolutely! You can find some example bundles here: https://aka.ms/example-bundles
Here is also a video of us running through some examples to give you a high level walkthrough of CNAB https://www.youtube.com/watch?v=26e5-UK4YRA
I'm even more confused after watching this video. Is the right way to think about this that it is a common specification that enables helm and compose to interoperate?
Re: Microsoft and Docker team up to make packaging cloud-native applications easier
#39This strikes me as possibly being somewhat similar to Habitat from Chef but, like Habitat at launch, I'm having a hard time understanding exactly what this does.
Re: Microsoft and Docker team up to make packaging cloud-native applications easier
#40I've been working on something similar with sugarkube[1]. It looks like it takes a different approach and aims to solve more of the toolchain. I'd be interested in feedback if anyone has the time... [1] https://github.com/sugarkube/sugarkube
Can you elaborate? It's not completely clear from the README.
Imagine you're running Wordpress on K8s. It actually needs ingress, Cert Manager for SSL certs and a DB. Locally you might want to use MariaDB for convenience, but in the cloud you want to use RDS.
Sugarkube lets you install everything in a single pass. In this example you'd create several different bundles (MS call them CNABs, I call them kapps to disambiguate them from apps which is an overloaded term). You'd create one for nginx ingress, one for cert manager, and one for wordpress. But the wordpress one is parameterised differently per environment to either create a MariaDB when running locally or RDS when running in the cloud. These bundles are just stored in a git repo.
Under the hood, Sugarkube calls Make with some predefined targets - right now just install, but in future also destroy - and passes a bunch of environment variables that the kapp declares that it needs. These can be loaded from a hierarchical YAML configuration which Sugarkube reads (kind of like hiera/puppet does). Oh, and it can template files as well.
'Make' just calls whatever you've implemented - Helm, terraform, any non-k8s stuff you need (there's no dependency on K8s in the architecture). You can easily drop down and ignore Sugarkube and just work directly with tools you already know.
Sugarkube also lets you control which versions of which bundles to release to your environments. It can support multiple live environments.
A final thing is it can also spin up clusters on a variety of backends - minikube, kops, and in future EKS/AKS/GKE, etc.
So altogether Sugarkube gives you a complete solution for launching clusters (ephemeral if you like), and installing your dependencies into them (all as a single golang binary).
Check out the example project (https://github.com/sugarkube/sample-project) which launches a minikube cluster, installs nginx-ingress, cert manager and 2 wordpress instances backed by MariaDB, and then loads different sample data into both databases.
It's still in preview but it can solve a real pain point around working with K8s and deploying applications.