feat: build and run from Docker Support #103
Conversation
|
This would be a quick way to create an environment where a developer could quickly start up and run the a blueprint in situations where they didn't want to, or couldn't, setup their dev env. Basically a docker image as dev env for the jhipster command. A blueprint quickstart of sorts (assuming you've got docker). Given the Entando use case this makes a lot of sense to me for our training and getting started cases. Would allow somebody to boot up and run the blueprint without setting up a dev env. We'll have to think about if we'd also want to recommend that they run the generated code inside the container. In that case we'd need to add some port forwarding and addressing for Keycloak and inbound traffic. @nshaw and @w-caffiero-entando thoughts on this? |
|
See also: May make more sense to extend an existing image. |
|
Hi Joe,
To which scenario are you referring?
1. Move the entire development environment on the container
2. Use docker only for the tooks and keep the files on the user host so
they can use their IDE
if it's the second, I was experimenting on a command line wrapper of a
jhipster-docker image (as well as the other entando-cli tools).
One of the problems I had was about the UID writing the files, which is the one of the docker container's user.
Sometimes you are lucky, in particular in personal systems with just one user, and the UID is 1000 for both the container and the host, sometimes your are not.
So I started experimenting on docker run capabilities in order to maps the user-id, but I haven't complete my tests.
Walter
…On 06/10/20 11:27, Joe White wrote:
This would be a quick way to create an environment where a developer
could quickly start up and run the a blueprint in situations where
they didn't want to, or couldn't, setup their dev env. Basically a
docker image as dev env for the jhipster command. A blueprint
quickstart of sorts (assuming you've got docker).
Given the Entando use case this makes a lot of sense to me for our
training and getting started cases. Would allow somebody to boot up
and run the blueprint without setting up a dev env.
We'll have to think about if we'd also want to recommend that they run
the generated code inside the container. In that case we'd need to add
some port forwarding and addressing for Keycloak and inbound traffic.
@nshaw <https://github.com/nshaw> and @w-caffiero-entando
<https://github.com/w-caffiero-entando> thoughts on this?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#103 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/APFQG666OF3PRXKWKBDFFBDSJLPJDANCNFSM4SFU3SLA>.
|
|
We'll have to think about if we'd also want to recommend that they run the
generated code inside the container. In that case we'd need to add some
port forwarding and addressing for Keycloak and inbound traffic.
This sounds more like the scenario #1, but how are they going to edit the
files?
Walter
On Tue, Oct 6, 2020 at 1:02 PM Walter Caffiero <[email protected]>
wrote:
… Hi Joe,
Of which scenarios are you referring?
1. Move the entire development environment on the container
2. Use docker only for the tooks and keep the files on the user host
so they can you their IDE on them
if it's the second, I was experimenting on a command line wrapper of a
jhipster-docker image (as well as the other entando-cli tools).
One of the prolems I had was about the UID writing the files, which is the
one of the docker container.
Sometimes you are luky, in particular in personal systems with just one
user, and it's 1000 for both the container and the host, sometimes your are
not.
So I started experimenting with the used management, then I've stopped.
Walter
On 06/10/20 11:27, Joe White wrote:
This would be a quick way to create an environment where a developer could
quickly start up and run the a blueprint in situations where they didn't
want to, or couldn't, setup their dev env. Basically a docker image as dev
env for the jhipster command. A blueprint quickstart of sorts (assuming
you've got docker).
Given the Entando use case this makes a lot of sense to me for our
training and getting started cases. Would allow somebody to boot up and run
the blueprint without setting up a dev env.
We'll have to think about if we'd also want to recommend that they run the
generated code inside the container. In that case we'd need to add some
port forwarding and addressing for Keycloak and inbound traffic.
@nshaw <https://github.com/nshaw> and @w-caffiero-entando
<https://github.com/w-caffiero-entando> thoughts on this?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#103 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/APFQG666OF3PRXKWKBDFFBDSJLPJDANCNFSM4SFU3SLA>
.
|
Using this , approach code generation on host machine folder from generator/blueprint running in container doesn't need to forward any port and address. After generation every generated file will remain on host system folder and container is automatically destroyed . After , User can proceed with development and deployment of generated service by building and running using either dev or prod profile. |
|
nshaw
dismissed
their stale review
Dismissing my approval/review per Walter's clarification about the UID handling.
Rajpratik71
force-pushed
the
feat/docker-support
branch
from
750ad8d to
5b43371
Compare
|
Added approach and step in Readme to work with interactive shell from inside the container |
Hi @w-caffiero-entando and @nshaw , I tested the UID scenario, the generated files have host machine permission . So , there is no concern remains about UID and permissions on files generated from container. |
Build and run the generator from docker image support added. The main aim and motivation behind doing this is, because of a no. of different jhipster blueprints are there, which are compatible and works with the different version of jhipster and also might be incompatible with other blueprints or versions of jhipster. Signed-off-by: Pratik Raj <[email protected]>
Rajpratik71
force-pushed
the
feat/docker-support
branch
from
5b43371 to
f50443c
Compare
|
@nshaw @w-caffiero-entando can we complete this ? |
|
Just to throw it in here, there's been a lot of work on the entando-cli tool lately (e.g. https://github.com/entando/entando-cli/blob/develop/bin/ent-jhipster) and it accomplishes some of the same goals without requiring docker, e.g. allowing switching between entando versions (and matching jhipster version), running jhipster using that version, etc. It should be ready along with Entando 6.3 which is entering QA soon. My only reservation with this PR is having too many ways to do the same thing which incurs maintenance overhead. @w-caffiero-entando, thoughts on this PR in that light? |
Build and run the generator from docker image support added.
The main aim and motivation behind doing this is, because
of a no. of different jhipster blueprints are there,
which are compatible and works with the different version of jhipster
and also might be incompatible with other blueprints or versions of jhipster.
Signed-off-by: Pratik Raj [email protected]