Yup. I remembered that can not give you an interactive shell when wrapped in gradle... 2016年2月25日 上午11:12於 "Konstantin Boudnik" <[email protected]>寫道：
> On Thu, Feb 25, 2016 at 10:34AM, Evans Ye wrote: > > Absolutely that's the way we should go! > > In fact, that's what we're doing in the docker-compose branch. > > It's not a problem to get container's name. But I can recall that I > didn't > > have a luck to get the following works: > > > > ./gradlew provisioner-attach bigtop1 #Then you get the bigtop1 > container's > > shell prompt. > > > > Do you have any suggestion? > > Were you running > docker exec -ti > for that? Do you remember? > > > > > 2016-02-25 8:52 GMT+08:00 Konstantin Boudnik <[email protected]>: > > > > > Recently I was dealing quite a bit with our provisioner and while it is > > > great > > > as is, there are still some ways we can improve both its complexity > (for > > > better maintenance), and UX for the users. > > > > > > Namely, I suggest we get rid of the ssh support for the docker > provisioner. > > > Instead, connecting to the container could be done via docker exec, > which > > > seems to be faster. There are at least two benefits in this: > > > - for a user to log into a container, you won't have to change > directory > > > to > > > run 'vagrant ssh bigtop1'. A user won't be even exposed to the > vagrant. > > > Instead, we can hook up the aforementioned exec to gradle so when > > > ./gradlew provisioner-attach bigtop1 > > > is ran, we will first figure out the full name of the container, > which > > > include 'bigtop1' substring; then run the exec command > interactively. > > > - similarly, the deployment would be less complex, as puppet commands > > > will be > > > ran directly without piping them into 'vagrant ssh ...' > > > > > > Thoughts? > > > Cos > > > > > > > > > >
