-
Notifications
You must be signed in to change notification settings - Fork 180
doc(applications): deploying add-ons #791
base: master
Are you sure you want to change the base?
Conversation
@slack, @mboersma and @krancour are potential reviewers of this pull request based on my analysis of |
src/applications/deploying-addons.md
Outdated
the application's configuration and will contain the URL used to access the newly provisioned | ||
service. | ||
|
||
You can choose the alias that the add-on uses on the application using the `--as` flag. This will |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How would this work with a broker that has multiple credential values, such as DB_USER
and DB_PASS
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a very good question. This is a straight cut from Heroku's docs and I'm not sure if it's a resonable effort to do this for a first pass. I'm not sure how Heroku handles this either as I know they have add-ons like Papertrail with multiple envvars. I'll go play around with some of their add-ons and see what works and what doesn't.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was thinking we could do some crazy docker-like mapping in the form of --as DATABASE_URL=DB_URL,DATABASE_USER=DB_USER
, but again I'm concerned about making the translation overly complex. I'm sure this will come into play as things start being implemented.
added |
removed the |
@bacongobbler, I think one needs to carefully read docs or interactive help to understand that |
I was trying to make it a 1:1 mapping with |
Is parity with Heroku still a concrete objective? In either event, I'm happy with what you have just proposed. |
Yes, because it's still a familiar toolset to many people, and that's still the general inspiration for Deis Workflow functionality. But it's not set in stone, if there's a good argument for doing things a different way--and it sounds like there might be here. |
I think this is a very good opportunity to change the heroku CLI names for specific commands. I agree that |
So as it turns out, instances are namespaced. Makes sense, but we haven't had to provision user-namespaced resources before... Everything was either an annotation on the application's service or on the router. What I think that means going forward is that we can introduce a Any opinions/thoughts on the matter, @krancour or @ultimateboy? |
From what it looks like, my assumption was wrong. instances and instance bindings must exist in the same namespace, so instances must be bound to the application then. That kinda sucks, because I had expected instances to be able to bind to an account and the bindings would be what the application cares about. I'll file a ticket upstream and see if there's a way we can work around this. As seen here, I have an instance in the
...And an instance binding in the
|
You know what, the idea of the instance and the instance binding living in the same namespace makes more sense anyways because in a team-centric world, all apps will be deployed in the same namespace as the team name so the instance should live in there. I'll be white-boarding this more overnight and try to come up with a better solution tomorrow. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I added a bunch of my $0.02 here 😄
src/applications/deploying-addons.md
Outdated
--------------- ---------------------- | ||
bonsai Bonsai Elasticsearch | ||
deis-postgresql Deis Workflow Postgres | ||
librato Librato |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does this list imply that the available services are provided as slugs? I have so many other questions, but I'll leave it at that for now 😄
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yep! The slug
and name
field relate directly with a service class' name and the description
field. I'll change the name
field to description
and slug
to name
to hopefully make things clearer. This is just how Heroku calls things.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So given the ups
broker is installed, deis addons:catalog
would look like:
name description
--------------------- ---------------------
user-provided-service User Provided Service
src/applications/deploying-addons.md
Outdated
``` | ||
$ deis addons:detach deis-postgresql:standard --app wooden-rowboat | ||
Detaching deis-postgresql:standard from wooden-rowboat... done, v6 | ||
``` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
what do you want to happen when a detach (unbind) happens before a deprovision?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So let's think about this in a team-oriented fashion:
- I have a team (a namespace to store all apps deployed by a team)
- I have many apps deployed in this namespace
- I have a few instances running in this namespace
I would expect that, as a user, I can bind an app to the instance as well as unbind apps from the instance.
This is essentially useless for the "instance in the app's namespace" use case though. Again I'll give this some more thought. :)
src/applications/deploying-addons.md
Outdated
``` | ||
|
||
If the application doesn’t yet have a database provisioned, a user can create a new database using | ||
the CLI. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a little confusing. Does this phrase:
a user can create a new database using the CLI
Refer to a provision operation?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Correct. It relates to an instance resource being created on the service-catalog's side.
Basically there are three operations:
- list the catalog
- CRUD the instances
- CRUD the instance bindings
src/applications/deploying-addons.md
Outdated
is using. | ||
|
||
``` | ||
$ deis addons:installed | grep -i postgresql |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How does someone get a new addon into this list? In service-catalog land, they'd do that by creating a Broker
resource. Is there an analog with the deis
CLI?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There is not. The expectation is that we will be listing the service classes, but the brokers themselves is managed by service-catalog and we are not adding any administration to service catalog. Just communicating with it similar to how we consume the kubernetes API.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So basically if an admin creates a new broker resource, it will populate new service classes into the mix for users to query via deis addons:catalog
I haven't added addons:catalog into the docs yet but I am going to amend these once again so users can list instances, bindings and service classes.
src/applications/deploying-addons.md
Outdated
# Deploying Add-ons | ||
|
||
The goal of `deis addons` is to give users the power to provision consumable services such as | ||
a postgres database, a minio bucket, or a logstash connection) to their applications. `deis addons` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The closing )
doesn't have an opening one to match.
|
||
As an example, most applications deployed by Workflow need a data store of some kind. `deis addons` | ||
allows applications to consume services like databases that exist somewhere via common environment | ||
variables like `DATABASE_URL`. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there a way for the app developer (the person who executes deis addons:attach
for example) to tell what env vars are available, after they do the attach operation (note there's no way in service-catalog land to tell what's available before the attach)?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I know that Heroku exposes them in config:list
. I'm sure we can do the same somehow.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
added more context lower down; should be available through deis config:list
.
@bacongobbler whether it should be possible to bind to instances in other namespaces was the subject of lots and lots of discussion very early on, but not so much as of late. I am of the opinion that in large enterprises and in microservice architectures, the notion of n applications all binding to a common instance that belongs to none of them (but is managed as its own thing) is probably not an uncommon use case. But that's not something that service catalog currently does because it would simply defy k8s existing permissions model and I don't think we were about to go re-inventing that. The practical implication of that is exactly what you seem to have concluded already-- that service instances and bindings for those instances should all be provisioned within an app's own namespace (or within a team namespace that contains multiple apps? is that a thing now?) Also, since Workflow is very app centric, would provision + bind be combined into a single step for Workflow users? |
c42dcd1
to
4576979
Compare
Nope! Just a twinkle in my eye.
Yes. Honestly I've just revamped the documentation again to only have 5 commands:
At the current time let's keep the instance + instance binding together with the app since all apps are in their own namespace. Had we deployed apps in a user's personal namespace (or implemented |
src/applications/deploying-addons.md
Outdated
Attaching deis-postgresql:standard to wooden-rowboat... done, v5 | ||
``` | ||
|
||
Once the instance has been attached to the application, a DATABASE_URL setting will be available in |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"setting" is a bit ambiguous. Change to "environment variable"?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
changed.
@bacongobbler I like where this is headed. It's clean and simple. There's a lot more complexity that could be exposed, but given Workflow's Heroku-esque focus on 12factor apps, this looks to be just right. 💯 |
d2e5145
to
9d3ff15
Compare
k, |
c0f6cc7
to
1360c72
Compare
This is the design document for
deis addons
and is currently a work-in-progress. This document is expected to change over time as work is being done.closes #741 once the work has been laid out and implemented.