Comments (37)
From @deis-admin on January 19, 2017 23:36
From @gabrtv on November 18, 2013 17:54
I've been working on a design for this with the Opscode guys. I hope to post a specification here shortly and get a PR together that implements a manual service registry that we can later make more dynamic (late binding, multi-tenancy, etc.)
from controller.
From @deis-admin on January 19, 2017 23:36
From @bacongobbler on December 1, 2013 8:37
@gabrtv, do you still have that spec hiding around somewhere for this issue? :)
from controller.
From @deis-admin on January 19, 2017 23:36
From @bacongobbler on December 4, 2013 23:23
Standalone Service Registry
The service registry is a wrapper to common web services for
centralized service creation (known as provisioning). It can work with
common on-premise services such as a local mysql database or a Redis server
for a "private" or on-premise service registry, or with public SaaS applications
such as MongoLab or ElephantSQL for a public service offering.
Technical Overview
This project will be a generic wrapper for web services, giving administrators
the power to make their consumable service readily available to any PaaS that
uses this service registry.
Similar to Heroku Add-ons, customers use the service registry to provision an
addon offered by a third-party provider for their applications. When this
happens, the service registry sends a request to a providers's service gateway,
which then creates a new private addon. This addon represents an instance of
the provider's service.
Target Market
The service registry aims to target the PaaS industry, where new PaaS vendors
are looking to add data services to their PaaS offering (similar to Heroku
Add-Ons). Private PaaS solutions may also implement this solution by
connecting to external databases or services instead, whether those services
are internal to a clustered environment or are in a large datacenter in another
region.
It also targets the SaaS market, where new providers are looking to get some
public visibility of their product through third parties that implement
this service in their offering.
Administrator's Spec
An administrator of the registry can manage all of the registered gateways.
You can view the gateways that are bound to the registry with the
deis services:list
command:
$ deis services:list
builtin-mysql
builtin-postgresql
amazon-rds-oracledb
mongolab
Registering a Gateway
Adds the gateway to the registry. The gateway is disabled by default.
$ deis services:add builtin-mysql --endpoint http://my-gateway-fqdn.com:port/
Adding builtin-mysql...done
Use `deis services:enable builtin-mysql` to enable this service
Unregistering a Gateway
Removes the gateway from the registry. Any addons created with this gateway
will NOT be deprovisioned when this gateway is removed.
$ deis services:remove builtin-mysql
Are you sure you want to remove builtin-mysql? (y or n)
Removing builtin-mysql...done
Disabling a Gateway
Disables a gateway, denying any calls to provision a new addon.
$ deis services:disable builtin-mysql
Enabling a Gateway
Enables a Gateway for use.
$ deis services:enable builtin-mysql
Developer Spec
A developer can manage their addons through the command line interface. You can view your current addons that are bound to your application with the deis addons:list
command:
$ deis addons:list
builtin-mysql:free
builtin-postgresql:free
amazon-rds-oracledb:small
mongolab:enterprise
Adding an Addon
Adds the addon to the application, and forces a new release.
$ deis addons:add builtin-redis --plan=free
Adding builtin-redis:free to myapp...done
Use `deis addons:docs builtin-redis --plan=free` to view documentation
Removing an Addon
Removes the addon from the application, and forces a new release.
$ deis addons:remove builtin-redis --plan=free
Removing builtin-redis:free from myapp...done
Switching Plans
Changes the addon credentials within the application to reflect the upgraded (or downgraded) plan's new endpoint. Forces a new release.
$ deis addons:update builtin-redis --plan=paid
Upgrading builtin-redis:paid to myapp... done
You are now being billed for this addon at $0.06/container/hr
Use `deis addons:docs builtin-redis --plan=paid` to view documentation
Opening an Addon's Dashboard
Opens a management page on the provider's website for the addon, giving the user administrative access to the addon.
$ deis addons:open builtin-redis
Opening builtin-redis:free for myapp.
Read Documentation on an Addon
Opens documentation on how to use the addon with the application.
$ deis addons:docs builtin-redis:free
Opening documentation on builtin-redis:free for myapp.
Registry Endpoints
GET /gateways
retrieve information about all gateways available
POST /gateways
attach a gateway to the registry
GET /gateways/:gateway_name
get information about this specific gateway
PUT /gateways/:gateway_name
update configuration for a gateway
DELETE /gateways/:gateway_name
unregister a gateway. also unprovisions all addons provisioned with this gateway
GET /addons
get information on all addons available
GET /addons?user=:username
get all addons provisioned by :username
GET /addons?gateway=:gateway_name
get all addons provisioned by a specific gateway
POST /addons
provisions a new addon
GET /addons/:addon_name
get information about the addon
PUT /addons/:addon_name
update an addon's config
DELETE /addons/:addon_name
deprovision an addon
Architecture Diagram
+-------------+ deis addons:add mysql --plan=free +--------+
| |-----------------------------------------| Client |
| Controller |-----+ +--------+
| | |
+-------------+ | POST /addons { type: mysql, plan: free }
| RETURN { status: 200, creds: { MYSQL_URL: ... }, name: mysql-746017aa }
192.168.0.1 | |
+------------+ | <-----------------+
| | |
| Registry |------+
| |
| | CREATE DATABASE 746017aa; GRANT USER ...;
+------------+ |
| |
| POST / { plan: free } |
| RETURN { status: 200, creds: {...} } |
| | |
| | 192.168.0.2 | 192.168.0.3:3306
| | +---------------+ | +---------------+
| V | | V | |
+---------------------| Gateway |-----------| MySQL |
| | | | |
| +---------------+ +---------------+
| 192.168.0.4 192.168.0.3:5432
| +---------------+ +---------------+
| | | | |
+---------------------| Gateway |-----------| PostgreSQL |
| | | | |
| +---------------+ +---------------+
| 192.168.0.5 http://mongolab.com/
| +---------------+ +---------------+
| | | | |
+---------------------| Gateway |-----------| MongoLab |
| | | |
+---------------+ +---------------+
from controller.
From @deis-admin on January 19, 2017 23:36
From @gabrtv on December 4, 2013 23:59
@bacongobbler This looks great. Let's flesh out the developer UX next. For example, how does a developer actually attach a database to an existing application using the CLI?
With Heroku this looks like heroku addons:add <provider>:<plan>
. Maybe for Deis this means deis services:add <provider>:<plan>
? What about the other parts of the lifecycle? Let's flesh that out, taking inspiration from Heroku's command-line workflow..
from controller.
From @deis-admin on January 19, 2017 23:36
From @bacongobbler on December 6, 2013 7:15
optionally, you should also be able to make this scriptable by specifying the --application=<appname>
option on any command, or whatever name makes most sense to make this command apply to a specific application.
from controller.
From @deis-admin on January 19, 2017 23:36
From @gabrtv on December 10, 2013 0:25
Thanks for this @bacongobbler. After much chin stroking and IRC discussion, here are the next steps before we can start implementation:
- Merge Upgrade/Downgrade into a single 'Change' or 'Update' function
- Change developer commands to
deis addons:action
-- for Heroku compatibility - Define ops/admin commands with
deis services:action
-- how does the admin inject services into the registry and manage them? - Revamp the spec into a single comment, so we can see the latest version all at once
Once we agree on moving forward, I suggest we start with a PostgreSQL reference implementation!
from controller.
From @deis-admin on January 19, 2017 23:36
From @bacongobbler on December 10, 2013 7:19
Features to discuss before this spec is considered final. These may also be cut from the final spec (as we don't need to concern ourselves with SPOF for now):
- optimally, the registry should have no Single Points Of Failure. This means that if the registry went down in the cluster, the entire system should still be usable.
- gateways and registries should have a shared secret key for authentication. We don't want someone to attach a rogue gateway to our registry, and we don't want to be the culprit of a MITM attack! This can be done using OAuth tokens.
- health management of the services. We should know when MongoLab is down or when our internal postgresql database is undergoing maintenance.
- more clarity on how the registry and the gateway communicate with each other (through bi-directional http API requests and OAuth tokens).
- how does a developer create their own custom service gateway?
from controller.
From @deis-admin on January 19, 2017 23:36
From @bacongobbler on December 15, 2013 0:33
Work in progress at https://github.com/bacongobbler/service-registry
from controller.
From @deis-admin on January 19, 2017 23:36
From @bacongobbler on January 7, 2014 10:23
It's very much alpha in it's current state, but I have a working proof of concept where the service registry will create and delete new MySQL databases, as well as return a URI for use. Documentation (and tests!) has still yet to be written, but you can try it out and see what kind of changes you guys would like to see.
Instructions on getting started:
- install the dependencies required for MySQL-python
- install rabbitmq for celery tasks
- run the following:
$ git clone git://github.com/bacongobbler/service-registry.git -b develop
$ cd service-registry
$ virtualenv venv && source venv/bin/activate
$ pip install -r requirements.txt
$ python manage.py syncdb --noinput
$ python manage.py runserver
- go to http://127.0.0.1:8000/api/v1/providers/, add a MySQL provider, enable it by ticking the checkbox, and click POST
- go to http://127.0.0.1:8000/api/v1/services/, add a new service with the name
asdfqwerty
, the new provider we just created, the free or paid plan, leave the URI field or write in it (will be overwritten later), any url for the dashboard, and any url for the docs.
After clicking POST to save, the entry should have been created, and the new database should be created in your local MySQL service. To verify, take a look at the uri
to ensure that it was populated, then open up a mysql shell:
$ mysql
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 13
Server version: 5.6.15 Source distribution
Copyright (c) 2000, 2013, Oracle and/or its affiliates. All rights reserved.
Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.
Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.
mysql> show databases;
+--------------------+
| Database |
+--------------------+
| information_schema |
| asdfqwerty |
| mysql |
| performance_schema |
+--------------------+
4 rows in set (0.00 sec)
mysql> select User from mysql.user;
+------------------+
| User |
+------------------+
| root |
| root |
| |
| |
| 8w685g6qkha3spot |
| root |
+------------------+
6 rows in set (0.00 sec)
For example, my uri field is now set to mysql://8w685g6qkha3spot:qrpsgu8yk64ig97h@localhost:3306/asdfqwerty
, so I can connect trying to use that information:
$ mysql -u 8w685g6qkha3spot -pqrpsgu8yk64ig97h asdfqwerty
Warning: Using a password on the command line interface can be insecure.
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 28
Server version: 5.6.15 Source distribution
Copyright (c) 2000, 2013, Oracle and/or its affiliates. All rights reserved.
Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.
Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.
mysql> show tables;
Empty set (0.00 sec)
from controller.
From @deis-admin on January 19, 2017 23:36
From @tombh on January 7, 2014 10:48
So exciting! Great work :)
The code's on the develop branch right?
from controller.
From @deis-admin on January 19, 2017 23:36
From @bacongobbler on January 7, 2014 15:42
the code's on the develop branch right?
Sorry, the instructions imply that it's currently on the develop branch. I'll be more explicit next time. You are correct! :)
from controller.
From @deis-admin on January 19, 2017 23:36
From @tombh on January 12, 2014 19:44
Just tried it and it worked first time out of the box ;)
What's next then? Is the plan for these endpoints to live on the official Deis API? I see that there'll be new commands for the CLI client. Will the Deis cookbook officially have recipes for certain 'built-in services'?
I'd like to help with this if I can. My Danabox project (formerly Crowdbox) is actually in private beta now and I think having database support is going to help encourage people to try it out.
from controller.
From @deis-admin on January 19, 2017 23:36
From @bacongobbler on January 12, 2014 22:30
Just tried it and it worked first time out of the box ;)
I try to keep a green policy for master :)
What's next then? Is the plan for these endpoints to live on the
official Deis API? I see that there'll be new commands for the CLI
client. Will the Deis cookbook officially have recipes for certain
'built-in services'?
The plan is to have this residing on the controller as a standalone web
app for now. Commands like deis addons:add builtin-mysql
will
communicate with this webapp through a POST request, which will then
receive the credentials as a response. The client should then inject
those credentials into the container, much like how deis config:set
accomplishes this (see
https://github.com/opdemand/deis/blob/master/client/deis.py#L778).
I'd like to help with this if I can. My Danabox project (formerly
Crowdbox) is actually in private beta http://danabox.io/ now and I
think having database support is going to help encourage people to
try it out.
By all means, please do!
from controller.
From @deis-admin on January 19, 2017 23:36
From @tombh on January 13, 2014 11:8
What's the reasoning for having a separate app? Sorry if this has been discussed elsewhere already. As a separate web app is it easy to piggyback off the API's cookie session from the CLI client? Is the idea to have it included in the official cookbook? And will there be recipes for built-in services in the cookbook?
The new commands in the CLI client should be pretty straightforward. So should we start a new branch on Deis to pull all these things together?
from controller.
From @deis-admin on January 19, 2017 23:36
From @bacongobbler on January 13, 2014 16:52
What's the reasoning for having a separate app? Sorry if this has been discussed elsewhere already. As a separate web app is it easy to piggyback off the API's cookie session from the CLI client?
Good question. I think a little background where I'm coming from is necessary...
I come from a cloudfoundry background, working on Stackato. Cloudfoundry's cloud_controller_ng has service discovery built in via a message bus called NATS and by using pub/sub techniques. The service registries (named service brokers in cfv2) are all separate sinatra apps, proxied together using an asynchronous proxy server. There is one service broker for each service (i.e. MongoDB, MySQL, Postgres, etc.), so each web app knows how to handle each service. It's convoluted, but it works. It has a couple advantages this way:
- you can put the webapp on a dedicated
services
node, which you can customize to your liking (i.e. increasing the disk size, memory, etc.) - It ensures that if your service node goes down, your cloud controller doesn't go down with it.
flynn.io is the same, in a sense. It has multiple micro apps all formed together to make one giant PaaS system, which are all discovered using discoverd, which is another service discovery system. It helps keep different offerings available on multiple servers, and in a perfect world, makes each system fully redundant (well, the service discovery is not necessarily redundant, nor is the controller). Cloudfoundry has this issue too, where they are trying to solve the problem of having no single points of failure in the cluster (currently, the message bus and the controller are SPOFs, though there may be other components that are just as likely to be a SPOF, too).
Unfortunately, Deis does not have service discovery yet (looking forward to seeing this in a future release 😉), so it'd probably make more sense to integrate this into the controller for now.
Is the idea to have it included in the official cookbook? And will there be recipes for built-in services in the cookbook?
The idea is the same with how you can enable or disable formation providers. You should be able to enable or disable certain service providers with a couple changes in api/models.py
. If you don't want mongodb available because you don't want any evil aGPL code in your infrastructure, then it should be as easy as flicking a switch in api/models.py
and a quick change in the cookbook to remove mongodb from being installed.
The new commands in the CLI client should be pretty straightforward. So should we start a new branch on Deis to pull all these things together?
Yes, a new branch would be good to put all this work back into the controller. dibs on 231-service-registry
:)
from controller.
From @deis-admin on January 19, 2017 23:36
From @tombh on January 14, 2014 13:59
That makes sense about isolating service discovery, you can't make the service-discoverer the same as one of the services that it is trying to discover.
So I made @bacongobbler's dibbed 231-service-registry branch with a basic integration of the service registry into the controller. Just wondering if it's the right direction to be heading in?
Sorry about the 3 commits. I forgot to remove the '.git' folder when copying in the service-registry repo and git thought it was a submodule ಠ_ಠ
Still to do:
- Add the returned URI to the app's config.
- All the other
addons:*
commands. - It still needs to have authentication set up, I'm imaging that it will piggyback off the session from the controller API?
- Cookbook recipe to install MySQL and register it as a provider.
from controller.
From @deis-admin on January 19, 2017 23:36
From @bacongobbler on January 14, 2014 17:27
So I made @bacongobbler's dibbed 231-service-registry branch with a basic integration of the service registry into the controller. Just wondering if it's the right direction to be heading in?
I like your approach, but if we're following Deis' current design pattern, the service code should be integrated back into the api
app, such as the models and the tasks, and the services.provider
should just be moved into a top level services
package.
Still to do:
- Add the returned URI to the app's config.
- All the other addons:* commands.
- It still needs to have authentication set up, I'm imaging that it will piggyback off the session from the controller API?
- Cookbook recipe to install MySQL and register it as a provider.
Tack on "add tests" to that list!
It still needs to have authentication set up, I'm imaging that it will piggyback off the session from the controller API?
Yes. It should be the same access controls. You should only be able to add a service to an application you have permission to create new releases for.
Cookbook recipe to install MySQL and register it as a provider.
Maybe that can be set up as a south
migration or a database seed? (the provider registration, not installing MySQL)?
from controller.
From @deis-admin on January 19, 2017 23:36
From @tombh on January 14, 2014 22:35
I did actually think complete integration was preferable. But then I wondered if it would be harder to extract out when the time came to make it standalone. Okay, so let's do it that way.
So should the models and tasks be appended to api/models.py
and api/tasks.py
? What do you mean by a 'services
package'? Like a services folder inside api/
?
Yes, tests of course! I forgot about them.
Yes, same access controls. That's pretty straightforward then if it's being integrated straight into the API app.
Yes, I think a south
migration would work for provider registration. Should it also work through the admin/
web interface as well? What about actually installing MySQL on the controller? You know, like with a recipe that does all the apt-get install
stuff? So you actually have an a MySQL instance on the node? I'm not so sure about that. Ideally it would be its own node wouldn't it? Or at least you should have the option of putting it on its own node. Already I want to write a postgres and redis providers! And we can't have the controller being filled up with all kinds of services can we?
from controller.
From @deis-admin on January 19, 2017 23:36
From @bacongobbler on January 15, 2014 0:21
So should the models and tasks be appended to api/models.py and api/tasks.py?
Yes.
What do you mean by a 'services package'? Like a services folder inside api/?
More like a services
folder at the root directory, much like how provider/digitalocean.py
is set up with api/tasks.py
. It would be the same for services/mysql.py
and api/tasks.py
.
Should it also work through the admin/ web interface as well?
All of the node providers/flavors are done in the same way, so yes :)
What about actually installing MySQL on the controller? You know, like with a recipe that does all the apt-get install stuff? So you actually have an a MySQL instance on the node? I'm not so sure about that. Ideally it would be its own node wouldn't it? Or at least you should have the option of putting it on its own node. Already I want to write a postgres and redis providers! And we can't have the controller being filled up with all kinds of services can we?
Installing MySQL can be just as easy as creating a new services
recipe in https://github.com/opdemand/deis-cookbook :)
I think this needs a bigger discussion, as this is a particularly larger subject all on its own. As this was just a proof of concept, all communication was done locally with a base install of MySQL (you can even see the code here). Ideally, It'd be nice to have this all on a separate deis layer, with the operations engineer being able to specify what services he would like on each node (maybe he wants builtin-mysql
and builtin-postgresql
on one node, and builtin-redis
on another), and then the controller could communicate with the nodes for provisioning requests and whatnot. The communication parts that are hardcoded at https://github.com/bacongobbler/service-registry/blob/master/provider/mysql.py#L12 could easily be moved back up to the Provider
model (which would have to be renamed to ServiceProvider
, I'd assume).
@gabrtv or @mboersma, any input from you guys on this topic?
from controller.
From @deis-admin on January 19, 2017 23:36
From @tombh on January 15, 2014 11:55
More like a services folder at the root directory, much like how provider/digitalocean.py is set up with api/tasks.py. It would be the same for services/mysql.py and api/tasks.py.
Ah, got it!
So, a service layer, that definitely sounds like the right way to go. But yeah part of a bigger discussion. So there'll be CLI commands like deis services:enable mysql
for instance? In fact, if that's the approach, then that's the point at which Provider.enabled = true
should be set, right? Not with a migration.
Might deis services
be a sort of convenience wrapper for deis layer
? The thing about a mysql node though would be that there is no point in scaling it. Unless you get into sharding!
I imagine there could be arguments to deis services
that specify which node to place the service on.
Definitely +1 for ServiceProvider
naming convention, got to try and avoid confusion with the infrastructure Provider
.
BTW I'm not wedded to implementing all this, I may not be the best person to do it. I'm just happy to do any grunt work.
from controller.
From @deis-admin on January 19, 2017 23:36
From @gabrtv on January 15, 2014 19:45
@bacongobbler @tombh When I get some time to breathe I plan to give this a more thorough review including a deep dive into the code. Here is my early feedback:
- It works? Awesome!
- I agree with putting the
services
package at the top level of the Deis project parallel withprovider
- Until we split out authn/authz into its own micro-service, we can't really modularize the API endpoints. We should host the new API endpoints alongside the existing ones (rather than spinning up a new gateway component).
- Single-point-of-failure shouldn't be an issue as the
Controller
will soon be scaleable horizontally on multiple containers across multiple machines.
On a related, service discovery via etcd
is coming sooner than you might think! \o/
from controller.
From @deis-admin on January 19, 2017 23:36
From @tombh on January 16, 2014 15:35
@gabrtv Thanks for the feedback :) I reckon I've got a good idea now of how to flesh out a prototype for this. I really want this on Danabox, so I'm going to crack on with it today and hopefully get it deployed there for some live testing soon. BTW, point 4 and containerisation in general is sounding awesome. I don't fully understand how etcd
fits into the puzzle yet, but sounds exciting.
from controller.
From @deis-admin on January 19, 2017 23:36
From @tombh on January 20, 2014 15:35
@stackedsax I was looking through the IRC logs and saw that you were interested in helping with the service registry branch. @bacongobbler's original code is here https://github.com/bacongobbler/service-registry and my WIP attempt to integrate it is here https://github.com/tombh/deis/compare/231-service-registry It's almost there. It works which is the main thing, so you can test it out. Off the top of my head you'll need to apt-get install mysql-server libmysqlclient-dev
and pip install MySQL-python==1.2.5
. I'm tidying things up and writing tests at the moment.
EDIT: Put wrong link to my dev branch
from controller.
From @deis-admin on January 19, 2017 23:37
From @bacongobbler on January 20, 2014 17:54
@tombh I've been working on some of this as well. I'll see what changes I can merge in from my own branch that I've been secretly hacking away on: https://github.com/bacongobbler/deis/compare/231-service-registry
from controller.
From @deis-admin on January 19, 2017 23:37
From @tombh on January 21, 2014 10:38
@bacongobbler Great. Or you could merge mine into yours. Something I've been stuck on, which I really don't know how to answer, is should (and how can) a ServiceProvider be associated with a formation/layer/node? I've also been thinking that the naming convention could be changed to further affirm the distinction from infrastructure providers. I'd suggest renaming ServiceProvider
to just Service
then Service
could become Addon
. That would then filter down to variable names and URL routes too.
Oh yes, I've been keeping track of the things I'm not sure on with a TODO comment that mentions '#231'.
from controller.
From @deis-admin on January 19, 2017 23:37
From @bacongobbler on May 5, 2014 18:2
Current status of the service registry (from #486):
There has been a lot of churn since this PR was made. While adding a service registry is not something that's blocking us from Deis v1.0, it's certainly something that's on my plate as an enhancement to Deis at some point in the future. Let's close this PR for now and keep the discussion moving forward in #231.
from controller.
From @deis-admin on January 19, 2017 23:37
From @recipher on May 6, 2014 9:19
As someone who has built a large Heroku deployment for a client, whilst using a range of 3rd party services (MongoHQ, Redis Cloud, etc), in all cases, we set up the external resource outside Heroku and just connect by manually setting the env variables. The Addons system is convenient but actually makes life more difficult sometimes by provisioning on a separate account, when sometimes you want things consolidated.
In Deis' case, I don't know if being able to use an api to setup and connect to a 3rd party is particularly necessary. What is necessary is being able to (simply) provision a resource within your own cluster, and get access to the necessary connection details. It might also be handy to link the docker containers, rather than exposing ports (as an option).
If someone could point me in the direction of some instructions about how to do that in the meantime, just using Docker, with, for example, Postgresql or Redis, that'd be great. I'm pretty certain I can work it out well enough (with my, presently, minimal Docker knowledge) but it'd be good to know if there was anything else needed to play nicely with Deis. Thanks.
from controller.
From @deis-admin on January 19, 2017 23:37
From @ianblenke on August 26, 2014 16:55
Requiring that plugins have external SaaS dependencies does seem to be the Heroku way.
Being that deis is Open Source, would a self-hosting plugin scaffolding for "templated" docker orchestration of such services make sense?
Being able to PaaS deploy containers in the Heroku buildpack way is a defining feature of deis at the moment.
Being able to PaaS deploy containers from a Dockerfile is a unique feature of deis, but currently lacks a number of abilities that make it attractive to Docker thinking folks. Things like volume mapping and running as privileged are often required by persistence layers and orchestration tools, but do violate the security model a bit in that they can interfere with and impede deis function by knowledge of its implementation. Simple port mapping would be a great boon, both to HTTP and non-HTTP protocols, but would tend to violate security in a multi-tenant hosting platform.
As immutable infrastructure for application deployment, deis is great!
Adding any form of scalable persistence or CAP theory clustering inside these containers requires careful orchestration. This means directly interfacing with the deis scheduler.
Dealing with that today, we use a Docker orchestration harness to independently manage the fleet deployed containers (fig, Orchard, maestro-ng, Centurion, etc).
These orchestration tools are currently unaware of the deis deployed containers. There is a deis api to poll for deis changes, but nothing in the way of an event webhook trigger to take action when the deis state changes.
The intersection of these two things is where this issue becomes relevant.
Having a plugin harness allows for external SaaS offerings. As Heroku has shown, for velocity of implementations and innovation, there is a need for that.
Having a scaffolding upon which to build Open Source "self hosting" internal services on deis itself is the golden ring here.
From the perspective of orchestrated "linking" of containers, it sure would be nice to be able to a Dockerfile deployed container to dynamically EXPOSE a port on the underlying fleet machine. After that, introduce a DSL (perhaps a Deisfile or Orchestrationfile) linking it to other deployed deis apps so that ports may be exposed as environment variables the same way as a Docker linked container is exposed.
As for scheduling coordination of rolls so as to not break persistence replication or CAP theory algorithms, there are many ways to accomplish that. Exposing these rules as part of a DSL (again, like a Deisfile or Orchestrationfile) may be one way. Exposing a scheduler API to allow orchestration tools sitting alongside deis to be more aware may be another.
I'm not saying do these things instead of the plugin services defined here. We definitely want to be able to hook out to external SaaS platforms as innovation happens there. What I am suggesting is that we begin to contemplate how we might self-host the implementations of Open Sourced services within the fleet as Open Source self-orchestrating solutions.
from controller.
From @deis-admin on January 19, 2017 23:37
From @jankramer on October 30, 2014 12:28
What's the current status and priority of this issue?
from controller.
From @deis-admin on January 19, 2017 23:37
From @bacongobbler on October 30, 2014 16:5
@jankramer we just announced v0.15 as our stable release candidate, which means new features will not be merged any time in the immediate future. That being said, I am tentatively assigned on this after our stable release, though we'll have to revisit the spec as it's been several months. Status is still the same as it was with deis/deis#231 (comment).
from controller.
From @deis-admin on January 19, 2017 23:37
From @jimmychu0807 on December 11, 2014 4:6
I am also working on this problem and would like to get Deis app be able to create and connect to an in-house backing services (hosted in Deis as well). I am thinking about the request flow. Currently it is using nginx to redirect http requests to various upstream servers.
When coming to other services not using http requests (say mysql on tcp requests) how would the Gateway/Router component works on the redirection? I tried nginx tcp proxy, but then realized TCP protocol doesn't support server_name directive in nginx as they have no "Host" field.
Another aspect is on managing the additional exposed ports on router for different kind of services. For this, when a new kind of service is added, we will need to rebuild the router container with additional exposed port and resubmit the router unit file to run the container with additional linked ports.
Am I on the right track with this thinking, or missing some aspects? Thanks.
from controller.
From @deis-admin on January 19, 2017 23:37
From @mboersma on January 2, 2015 15:41
This came up again on IRC, so here is a proxy +1 on this issue; it is very much wanted.
from controller.
From @deis-admin on January 19, 2017 23:37
From @ianblenke on March 1, 2015 7:32
This came up again this week with regard to having a plugin to support submodules (being that git archive strips the .git directory) as mentioned in #3157
from controller.
From @deis-admin on January 19, 2017 23:37
From @ianblenke on March 8, 2015 18:21
Flynn has a service control plane of sorts:
https://flynn.io/docs/postgres
At the moment, it seems to be a certain amount of manual json to add your own persistence service layers based on docker containers:
https://gist.github.com/lmars/fca0f18b4ecd507fb39a
Similarly, tsuru has a services layer:
http://docs.tsuru.io/en/stable/services/index.html
There are some great ideas and parallel development going on in this space. Might not be a bad idea to take a quick look and understand the directions they are headed.
from controller.
From @deis-admin on January 19, 2017 23:37
From @bacongobbler on March 8, 2015 21:2
We've been keeping our eyes on Cloud Foundry's Service Broker as well as the corresponding API as I am intimately familiar with it, but we're open to look at what other PaaSes have done for an initial proposal.
from controller.
From @zeiv on January 21, 2017 17:7
Is there anything I or other community members can do to help with this? This feature will be awesome. Thanks for all the great work!
from controller.
From @bacongobbler on January 21, 2017 17:35
@zeiv you may want to take a look at https://github.com/kubernetes-incubator/service-catalog and sig-service-catalog if you're interested in this feature!
from controller.
Related Issues (20)
- Ignore pod scheduling errors during deployments HOT 10
- Support for apps/v1 deployments HOT 4
- HPAs are not re-created upon controller start if they have been deleted in Kubernetes (but still exist in workflow) HOT 1
- Update docker-py to docker python package
- Recreate all migrations for django 2.2 upgrade. HOT 4
- Upgrade the flake package for testing and fix python3 style errors
- Dockerfile + Procfile disaster recovery issue restoring scale
- Can't remove user's permission from an app when username is an email address HOT 3
- Unclear error message when setting memory limits HOT 3
- SSL certificate-key pairs are not validated before storage (RSA) HOT 2
- The ability to define an ENV var that is in fact a secret
- The ability to define `GUNICORN_WORKERS` and `CONN_MAX_AGE` env vars via helm chart's values HOT 12
- After deis apps:destroy the namespace stuck at Terminating forever HOT 5
- Ingress annotations should be set globally by hephy-controller HOT 7
- Address deprecation warnings and upgrade djangoRESTframework
- (app::deploy): list index out of range while dais pull HOT 4
- Change API endpoint for HPA autoscaling
- Controller should give more detail per Proc types
- The new controller v2.20.1 release is broken on (some?) GKE clusters HOT 11
- AKS deis-controller at v2.20.1 can no longer scale process types HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from controller.