Microsoft and Docker team up to make packaging cloud-native applications easier
techcrunch.com
techcrunch.com
- https://open.microsoft.com/2018/12/04/announcing-cnab-cloud-...
EDIT: As a cloud systems architect, I view participation in CNCF as a positive signal.
I'm not very familiar with Ansible, etc., so maybe tools like that have strategies for building deterministic environments, but I can see a lot of people putting `apt-get` or `yum` commands in an install script.
For example, see how you can build a CNAB using a Terraform base image: https://github.com/deislabs/bundles/tree/master/terraform
Currently, we provide developers with lab environments that wire together a small subset of containers under Docker compose for local development because running the full system is impractical. However, most of our lab environments may have important external dependencies (i.e. Slack, SMTP gateways, etc) that require configuration and often secrets.
One challenge of maintaining these lab environments is keeping these external configuration details up to date, so it would be helpful if the CNAB spec allowed configuration of this sort to be provided by an external provider similar to how Docker images themselves are expected to be provided by a container registry.
Have you anticipated this use case? If so, does CNAB have this type of support?
https://github.com/deislabs/cnab-spec/blob/master/802-creden...
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!
I’ve been developing for and on Windows for over 20 years. The “Windows Tax” didn’t become a concern of mine until I started using cloud providers. The cost of Microsoft’s licenses was someone else’s problem.
But, when every resource you use is tagged and it’s very clear how much you’re spending on an implementation, the double hit of Windows becomes real. First you pay more for Windows VMs than the same size Linux VMs and then you need more resources.
I can do a lot with a 256Mb-512Mb RAM Linux VM. I at least need 4GB of RAM for Windows and that’s stretching it.
On the other hand, I still love .Net Core but it’s not getting the uptake that Node is or even Java - yes that makes me sad.
If your apparent virtual size is 2.6GB but there's actually only 240MB of resident memory, Linux will run on 256MB of RAM. NT requires enough RAM for the entire 2.6GB plus overheads.
This is especially frustrating if you have orchestration services that would have recovered from the unlikely event of OOM since avoiding OOM is literally the only reason for NT's choice.
Windows has a lot of ways to develop for Linux/Unix now. It sure isn't FOSS, but let's not discourage a promising way to get more people into software, even if it's on Windows.
Hint- no circular arguments allowed. For example- UNIX line endings are '\n' so they are better so look UNIX is better. I mention this because I've heard this from my friends none of whom have ever programmed a raw terminal.
We actually chose not to use Docker for a group project in undergrad because some group members didn't have Windows Pro.
I'm asking because in the Ansible example in https://github.com/deislabs/bundles/blob/master/ansiblebase/... I see AZURE_TENANT AZURE_CLIENT_ID AZURE_SECRET AZURE_SUBSCRIPTION_ID but nothing for other clouds.
Would you have to add configuration for every cloud you have to support?
It seems that in this context cloud agnostic means any cloud can be supported.
I'm interested in application portability [0]. To do this with CNAB you need to add every cloud to the bundle. This is contrast to something like Crossplane [1] that intents to support multi-cloud with a single specification.
0. https://medium.com/gitlab-magazine/multi-cloud-maturity-mode...
I get the specification is cloud agnostic. But it looks like the developer needs to write the underlying code to provision and maintain the application on the various clouds. It feels like a too thin abstraction. And it seems pretty leaky currently; the examples all have hard and specific requirements e.g. Azure, k8s etc.
What am I missing? Is the idea that we will create tooling to automatically create the provisioning and maintenance code?
Does it run on Linux?
From my understanding, you've got Docker for defining your app's services, you've got Kubernetes for orchestrating them, you've got Terraform et al. for defining/configuring your infrastructure, and now you've got CNAB/Duffle to bring all these tools and configs together under one umbrella.
> Does it run on Linux?
From the article[1] posted above:
> By design, it is cloud agnostic. It works with everything from Azure to on-prem OpenStack, from Kubernetes to Swarm, and from Ansible to Terraform. It can execute on a workstation, a public cloud, an air-gapped network, or a constrained IoT environment.
[1] https://open.microsoft.com/2018/12/04/announcing-cnab-cloud-...
But imagine you need to run your Helm chart on Kubernetes environment that doesn't have access to your container images. You could build a thick bundle from your Helm chart, put it on USB stick, sneaker-net it over to a disconnected Kubernetes cluster, hydrate a container registry and run the Helm chart with full fidelity in the new environment.
This is just one thing CNAB enables..
But I see CNAB falling into the same trap as Helm, and many of the package managers before them (including newer variants with things like charm/juju), an archive with some notion of lifecycle events is not enough. Even though it's cute that lifecycle events are encapsulated in containers making it easier to manage their runtime dependencies.
What I think makes Crossplane's model more attractive is the notion of building on top of Kubernetes design and leveraging things like the operator pattern[2]. Now application stacks can do more interesting actions during their lifecycle, which can work to preserve availability during an event (like upgrading your application stack). Crossplane is about expanding the management of resources beyond just containers running in your cluster, but to any resource you can model in the K8s control plane and writing software that can react to events related to those resources.
[1] https://blog.upbound.io/introducing-crossplane-open-source-m... [2] https://coreos.com/operators/
Take the example of deploying serverless functions and a cloud based datastore (like CosmosDB) with a 3rd-party DNS service. Kubernetes operators are a poor fit for this, as they presume the existence of a Kubernetes cluster.
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] illustrates that.
So, I guess I am confused. You have users that want to package their app in containers, and run those containers. However, those users don't want to use Kubernetes APIs to do it? Why?
[1] https://docs.google.com/document/d/1RmHXdLhNbyOWPW_AtnnowaRf...
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 CNAB is tackling.
"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 of CNAB is to run a container. And CNAB invents a new way of configuring, lifecycling, etc, this container image.
[1] https://github.com/deislabs/cnab-spec/blob/master/100-CNAB.m...
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.
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!
He told me that he and his team saw the need for something like CNAB after finishing their work on Helm 2, but that they would keep working on Helm 3. He also explained that Helm could be used to install some or all components of an application bundled in CNAB format, which makes sense.
I have spent all day today trying to switch from running Docker in a Vagrant to running Docker for windows and can say without question that Docker and Windows are incompatible as of today.
Specific issues are numerous, but primarily it is slow, and has stupid defaults, volumes will drive you nuts, don't use with cygwin or Ubuntu for Windows either (volumes won't work) and expect everything to crash your terminals.
You are able to develop and deploy your code only because Microsoft allow you to.
But it's OK, Microsoft love "Open Source".
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.
Ie: K8s for humans?
Is it Helm?