feat: build and run from Docker Support

[Rajpratik71]

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]

[joewhite101]

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?

[joewhite101]

See also: https://github.com/jhipster/jhipster-quarkus/pull/102

May make more sense to extend an existing image.

[w-caffiero-entando]

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 https://github.com/entando/entando-blueprint/pull/103#issuecomment-704147179, or unsubscribe https://github.com/notifications/unsubscribe-auth/APFQG666OF3PRXKWKBDFFBDSJLPJDANCNFSM4SFU3SLA.

[w-caffiero-entando]

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 https://github.com/entando/entando-blueprint/pull/103#issuecomment-704147179, or unsubscribe https://github.com/notifications/unsubscribe-auth/APFQG666OF3PRXKWKBDFFBDSJLPJDANCNFSM4SFU3SLA .

[Rajpratik71]

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?

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]

1. I could see the benefits of running the tools in a container (option#2 per @w-caffiero-entando ) to avoid dependency mismatches, etc. as long as it's an option rather than something we require. I've run into a few of those issues in training, documentation tasks, etc.
2. I would be very unlikely to want to run the IDE from inside the container though.
3. I'm on the fence on whether the benefit of running the entire blueprint from inside the container outweighs the added complexity of supporting it. At some point we're getting into Kubernetes territory. Side note, this reminds me of the gap in our documentation re explaining our recommended/typical development environment where you spin up a blueprint and point it to an external keycloak, microservices, etc. That's not quite the same thing but related.

[Rajpratik71]

Added approach and step in Readme to work with interactive shell from inside the container

[Rajpratik71]

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.

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.

[Rajpratik71]

@nshaw @w-caffiero-entando can we complete this ?

[nshaw]

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?