Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Microsoft and Docker team up to make packaging cloud-native applications easier

techcrunch.com

Post reply on HN
Print view View original

21–30 of 83 posts

Re: Microsoft and Docker team up to make packaging cloud-native applications easier

#21

Post by mnoorali »

donmcronald wrote: post #7
gabrtv wrote: post #4

Gabe 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-...

I wonder if I'm misunderstanding. Why would I want install, uninstall, etc. type actions running in a Docker container? Isn't that going to encourage people to spin up production environments that aren't reproducible? 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 instal…

The goal with CNAB is to be able to version your application with all of its components and then ship that as one logical unit making it reproducible. The package format is flexible enough to let you use the tooling that you're already using.

Re: Microsoft and Docker team up to make packaging cloud-native applications easier

#22

Post by gabrtv »

donmcronald wrote: post #7
gabrtv wrote: post #4

Gabe 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-...

I wonder if I'm misunderstanding. Why would I want install, uninstall, etc. type actions running in a Docker container? Isn't that going to encourage people to spin up production environments that aren't reproducible? 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 instal…

CNAB makes reproducibility possible by providing unified lifecycle management, packaging, and distribution. Of course if bundle authors don't take care to work around problems with imperative logic, that's a risk. In practice, we see declarative models for building bundles offer more reproducibility.

For example, see how you can build a CNAB using a Terraform base image: https://github.com/deislabs/bundles/tree/master/terraform

Re: Microsoft and Docker team up to make packaging cloud-native applications easier

#23

Post by politician »

gabrtv wrote: post #17
politician wrote: post #8

Earlier quoted context omitted.

Do CNAB bundles support the ability to specify where parameter and credential details might be fetched from? 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…

Yes. See credential sets in the specification. https://github.com/deislabs/cnab-spec/blob/master/802-creden...

Thanks Gabe, this looks promising.

Re: Microsoft and Docker team up to make packaging cloud-native applications easier

#24

Post by philips »

gabrtv wrote: post #20
tjfontaine wrote: post #18

Both crossplane[1] and CNAB are attempting to play in similar spaces, understanding that deploying an application for the cloud (public or private) is more than just dumping your software into an image and giving it to a provider (be it K8s or some other IaaS/PaaS stack). There's more associated with the application, specifically what it means to orchestrate IaaS/PaaS/SaaS to realize your application. But I see CNAB…

We are big fans of Kubernetes operators. However, taking a dependency on Kubernetes to solve this problem is not something our customers want. CNAB design acknowledges this, and leans on the concept of invocation images to perform lifecycle management. 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 th…

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] 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://github.com/virtual-kubelet/virtual-kubelet

Re: Microsoft and Docker team up to make packaging cloud-native applications easier

#25

Post by tjfontaine »

philips wrote: post #24
gabrtv wrote: post #20

Earlier quoted context omitted.

We are big fans of Kubernetes operators. However, taking a dependency on Kubernetes to solve this problem is not something our customers want. CNAB design acknowledges this, and leans on the concept of invocation images to perform lifecycle management. 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 th…

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]…

Precisely, the dependency we're talking about here is "just" leveraging Kubernetes as a generic extensible control plane which makes it quite convenient to plug into for management of resources.

Re: Microsoft and Docker team up to make packaging cloud-native applications easier

#26

Post by gabrtv »

philips wrote: post #24
gabrtv wrote: post #20

Earlier quoted context omitted.

We are big fans of Kubernetes operators. However, taking a dependency on Kubernetes to solve this problem is not something our customers want. CNAB design acknowledges this, and leans on the concept of invocation images to perform lifecycle management. 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 th…

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 CNAB is tackling.

Re: Microsoft and Docker team up to make packaging cloud-native applications easier

#28

Post by busser »

I was at DockerCon EU today when Matt Butcher announced this. I wondered how CNAB would relate to existing cloud native package managers like Helm, especially since a big part of Helm comes from Matt himself.

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.

Re: Microsoft and Docker team up to make packaging cloud-native applications easier

#29

Post by philips »

gabrtv wrote: post #26
philips wrote: post #24

Earlier 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…

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 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...

Re: Microsoft and Docker team up to make packaging cloud-native applications easier

#30

Post by donmcronald »

gabrtv wrote: post #22
donmcronald wrote: post #7

Earlier quoted context omitted.

I wonder if I'm misunderstanding. Why would I want install, uninstall, etc. type actions running in a Docker container? Isn't that going to encourage people to spin up production environments that aren't reproducible? 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 instal…

CNAB makes reproducibility possible by providing unified lifecycle management, packaging, and distribution. Of course if bundle authors don't take care to work around problems with imperative logic, that's a risk. In practice, we see declarative models for building bundles offer more reproducibility. For example, see how you can build a CNAB using a Terraform base image: https://github.com/deislabs/bundles/tree/maste…

Yeah. I read through some of those existing configs and I see how it works now. My first instinct when I see `cnab/app/run install` is to think it's for installing the app, but now I see it's for provisioning / deploying to the environment. As soon as I think of install, uninstall as deploy, undeploy then it clicks for me.
Post reply on HN