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!
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 install script.
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 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?
I am one of those people who learn through examples. Do you have an example of using duffle for defining some sort of application? I work with this stuff and the websites are so abstract as to what it does and the spec is so low level...
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 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.
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 this, as they presume the existence of a Kubernetes cluster.
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.
I’m an avid user of both docker compose and kubernetes/helm, and have been very frustrated by the lack of interoperability between them. This looks like it might get us there, which makes me very happy. Nice work Microsoft and Docker.
Thanks! We're excited about the opportunity to align Compose and Helm with a standard packaging/distribution/management model. Same is true for other tooling like Terraform, Ansible, and cloud provider declarative APIs (Azure Resource Manager, etc).
NOTE: THIS HEADLINE DOES NOT MEAN THAT DOCKER WORKS IN WINDOWS
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.
The trick is to install the legacy docker toolbox with kitematic and docker-compose. The desktop shortcuts dont wirk, so you will need to also fix those. You will also need ensure you are using the oracle vm virtual box. Its all a real pain to get to work, but it seems to be ok, for simple projects.
This 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.
I'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...
[+] [-] gabrtv|7 years ago|reply
- https://cnab.io
- https://duffle.sh/
- https://open.microsoft.com/2018/12/04/announcing-cnab-cloud-...
[+] [-] mcny|7 years ago|reply
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!
[+] [-] donmcronald|7 years ago|reply
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.
[+] [-] politician|7 years ago|reply
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?
[+] [-] politician|7 years ago|reply
EDIT: As a cloud systems architect, I view participation in CNCF as a positive signal.
[+] [-] sytse|7 years ago|reply
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?
[+] [-] ilaksh|7 years ago|reply
Does it run on Linux?
[+] [-] ravedave5|7 years ago|reply
[+] [-] polskibus|7 years ago|reply
[+] [-] patrickaljord|7 years ago|reply
[+] [-] throwaway981298|7 years ago|reply
[deleted]
[+] [-] tjfontaine|7 years ago|reply
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/
[+] [-] gabrtv|7 years ago|reply
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.
[+] [-] jjm|7 years ago|reply
[+] [-] busser|7 years ago|reply
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.
[+] [-] zapita|7 years ago|reply
[+] [-] gabrtv|7 years ago|reply
[+] [-] amirhirsch|7 years ago|reply
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.
[+] [-] sbhn|7 years ago|reply
[+] [-] ttty|7 years ago|reply
[+] [-] anime_forever|7 years ago|reply
[+] [-] yarrel|7 years ago|reply
You are able to develop and deploy your code only because Microsoft allow you to.
But it's OK, Microsoft love "Open Source".
[+] [-] AlexB138|7 years ago|reply
[+] [-] codereflection|7 years ago|reply
[+] [-] skboosh|7 years ago|reply
[1]https://github.com/sugarkube/sugarkube
[+] [-] nprateem|7 years ago|reply
[+] [-] CyanLite4|7 years ago|reply
[+] [-] unknown|7 years ago|reply
[deleted]
[+] [-] the_common_man|7 years ago|reply
[+] [-] john_moscow|7 years ago|reply
[+] [-] crsv|7 years ago|reply
[+] [-] bacongobbler|7 years ago|reply
[+] [-] holografix|7 years ago|reply
Ie: K8s for humans?
[+] [-] webwanderings|7 years ago|reply
Is it Helm?
[+] [-] bacongobbler|7 years ago|reply
[+] [-] 013a|7 years ago|reply
[+] [-] gabrtv|7 years ago|reply