Open Cryptophobia opened 6 years ago
From @deis-admin on January 19, 2017 21:15
From @PierreKircher on December 6, 2014 14:30
wont work everywhere ..:> http://content.screencast.com/users/blackdolpinmedia/folders/Jing/media/e712a502-2c06-4fce-bca6-40d54557d8c7/00000013.png
to example .. is a simple vrrp ( floating ip aka lbl construct ) .. the nodes them self just got a privat lan.. so youd need to push the stuff throw the lbl + register the registry on the deis-router which is not the case right now .. nor does deis support auth for the internal reg .. (security consirn) .. use a external privat registry .. thats the best bet right now
From @deis-admin on January 19, 2017 21:15
From @renegare on December 6, 2014 14:49
@PierreKircher the hackyway I described above, is by creating a direct connection to the deis-registry (and has nothing to do with a load balancer or router). One can use fleetctl / deisctl to track down the IP of the deis-registry unit.
What I never made clear from the beginning is that deis does not currently support private docker registries (correct me if i am wrong). And that was the driving factor of this.
Not every one pushes through the Buildpacks, and Dockerfile deployment takes a long time to build.
Finally: no deis components have been modified in order to achieve this. More of hacked work flow than a hack in the code.
From @deis-admin on January 19, 2017 21:15
From @mboersma on December 6, 2014 15:38
@renegare we did actually have a PR at one point to add deis push
to the mix: https://github.com/deis/deis/pull/1412. I can see how it would be useful. I've kept these commits in a branch in case we want to resurrect it. I think the main issue was how to deal with registry authentication, but there may be more to it than that.
From @deis-admin on January 19, 2017 21:15
From @renegare on December 9, 2014 12:36
@mboersma, am I right in assuming that if we had a deis push
command, all requests will need to go through the lbl > router > controller > registry
?
If so (which I think is entirely possible) performance concerns me and will invalidate the usefulness of this feature. E.g. pushing a heavy image blocks other app requests from getting through etc ...
How does git push
flow internally work from a high level?
From @deis-admin on January 19, 2017 21:15
From @bacongobbler on December 9, 2014 16:6
http://docs.deis.io/en/latest/understanding_deis/concepts/#build-release-run
git push
goes from lbl > router > builder
, which builds the image, pushes it to the registry and notifies the controller that a new build has been created.
From @deis-admin on January 19, 2017 21:15
From @wenzowski on March 11, 2015 8:15
/bump to join this thread
From @deis-admin on January 19, 2017 21:15
From @carmstrong on June 7, 2015 19:55
This feature is on our open roadmap: http://docs.deis.io/en/latest/roadmap/roadmap/
From @deis-admin on January 19, 2017 21:15
From @renegare on June 8, 2015 13:46
Nice one guys. Been AWOL, but great to see this.
From @deis-admin on January 19, 2017 21:15
From @bacongobbler on June 26, 2015 22:24
So to think about this feature, there are a few things I can think of. If this is good, then I'll move to a more formal proposal with doc changes:
docker push
with the auth server + a call to the controller to create a new builddeis pull
with this new workflow. This might be just a big fat warning in the client before we remove those endpoints in a future release.Does that seem reasonable to everyone? :)
From @deis-admin on January 19, 2017 21:15
From @aledbf on June 26, 2015 23:32
@bacongobbler please do not remove deis pull
. I use a remote registry to deploy to production, not something from a local docker graph
From @deis-admin on January 19, 2017 21:15
From @bacongobbler on June 26, 2015 23:38
I guess there's no true need to remove it. The motivation to remove deis pull
is that it's a giant hack to pull in an image, with intimate logic around the v1 image layer format. It doesn't work with v1.6+ images at all and we cannot support it with the v2 registry unless we re-implemented the crazily slow "pull, push, pull" workflow with a docker engine, so we'd need to do that in tandem with #3814.
cc'ing @mboersma for visibility since he's working on the v2 registry
From @deis-admin on January 19, 2017 21:15
From @alexanderkiel on August 25, 2015 21:17
I really like the idea from @renegare of a simple deis deploy <image>
and I like to extend it to remove the need of a deis push
before it. The deis client could handle the retrieval of local or remote images and just deploy it through one single API. There is no need that the deis servers pull images from somewhere or that I have to push images into the deis registry before I can deploy them. All I want to do is: create an app, deploy an image and config it.
From @deis-admin on January 19, 2017 21:15
From @renegare on December 6, 2014 14:25
Currently as of
deis v1.0.2
all of this is possible, but through the [not so elegant] steps:This clearly not elegant (I have it running on a CI #ignant) and a few too many moving parts.
I'm hoping for a discussion around this, I am still oblivious to any related concerns around the possibility of this feature.
Copied from original issue: deis/deis#2680
Copied from original issue: deis/workflow#709