[keycloak-dev] Branches for the quickstarts

Marko Strukelj mstrukel at redhat.com
Fri May 19 10:05:11 EDT 2017


I believe nowadays the tech to use for such multiserver setups would be
Docker / OpenShift.

On May 19, 2017 14:50, "Stan Silvert" <ssilvert at redhat.com> wrote:

> On 5/19/2017 8:29 AM, Stian Thorgersen wrote:
> > I repeat - Quickstarts are to help people getting started securing
> > their own applications.
> >
> > What you are proposing will not help for that. We don't support
> > deploying apps directly to Keycloak. It's an SSO solution after all.
> > So it's just part of it running Keycloak on a different port or host.
> Also, I don't think I explained very well how this works.  There are two
> completely different servers that just happen to share the same /modules
> directory:
>
> /modules
> /standalone
> /keycloak
>
> >
> > On 19 May 2017 at 14:15, Stan Silvert <ssilvert at redhat.com
> > <mailto:ssilvert at redhat.com>> wrote:
> >
> >     On 5/19/2017 3:06 AM, Stian Thorgersen wrote:
> >>     That's rather off topic. Quickstarts is one thing and a
> >>     demo/example is another thing. Quickstarts is supposed to show
> >>     you how to get started with securing your apps with Keycloak.
> >>     What you are proposing is a nice option on just trying out
> >>     Keycloak, but it doesn't really help users getting started
> >>     properly with securing their apps.
> >     I disagree.  It would help tremendously. Right now, to get started
> >     securing your apps with the help of quickstart you must:
> >     1) Set up a Keycloak instance and understand that you need to run
> >     it on port 8180.
> >     2) Set up a Wildfly instance on port 8080.
> >     3) Find multiple json files that you need to import to Keycloak
> >     3.5) If you can't figure out what to import, follow the
> >     instructions to do Keycloak config by hand.
> >     4) Create keycloak.json files for each app and put them in the
> >     proper place.
> >     5) Do mvn wildfly:deploy for each app you want to run
> >     6) FIGURE OUT WHAT YOU DID WRONG IN STEPS 1-5
> >     7) Try modifications to the quickstart apps so you can get an
> >     ideas about how you will secure your own apps
> >     8) Deploy your modifications
> >
> >     What I propose is that we get rid of steps 1 through 6.
> >     Quickstart doesn't help if you can't get to steps 7 and 8 "quickly".
> >
> >
> >>
> >>     On 18 May 2017 at 20:59, Stan Silvert <ssilvert at redhat.com
> >>     <mailto:ssilvert at redhat.com>> wrote:
> >>
> >>         What we really need for the quickstarts is something Bill has
> >>         been
> >>         talking about for a long time.
> >>
> >>         It's a bundle of Keycloak and examples that just boots up and
> >>         works.
> >>         Otherwise, the quickstarts are way too hard to get running.
> >>         Nobody
> >>         wants to spend 2 or 3 hours on a "quickstart". That's what I
> >>         had to do
> >>         recently and I already know what's going on.  I hate to think
> >>         about what
> >>         someone new to Keycloak needs to go through just to see an
> >>         example.
> >>
> >>         This doesn't have to mean that everything runs in the same
> >>         WildFly
> >>         instance like the old demo dist.  The problem with that was
> >>         that it
> >>         didn't show Keycloak set up as a stand-alone server.
> >>
> >>         What you need is a single bundle that lets you run Keycloak
> >>         standalone
> >>         and a standalone app server.  I see a couple of ways to do it:
> >>         1) Use domain mode where you get a domain controller,
> >>         Keycloak instance,
> >>         and app server instance all in the same JVM.
> >>         2) Use two separate server configs and run in two JVM's.
> >>
> >>         I think #2 is the best.  The Keycloak instance runs on port
> >>         8180 and the
> >>         app server runs on 8080.  You only need one download of
> >>         WildFly/Keycloak, but you package it with two configs.  So
> >>         you have:
> >>         /bin
> >>         /modules
> >>         /domain (don't actually need this one)
> >>         /standalone
> >>         /keycloak
> >>
> >>         To run Keycloak (preloaded with quickstart realm):
> >>          > standalone --server-config=keycloak
> >>         -Djboss.socket.binding.port-offset=100
> >>
> >>         To run app server (preloaded with quickstart apps):
> >>          > standalone
> >>
> >>
> >>
> >>         On 5/18/2017 1:59 PM, Bruno Oliveira wrote:
> >>         > Hmmm I'm not sure about that. That would be the completely
> >>         opposite of what
> >>         > we already do to any repository today. If people want the
> >>         stable release of
> >>         > the quickstarts they could just get 3.x or download the zip
> >>         files, nope?
> >>         >
> >>         > On Thu, May 18, 2017 at 2:15 PM Sebastien Blanc
> >>         <sblanc at redhat.com <mailto:sblanc at redhat.com>> wrote:
> >>         >
> >>         >> We should also consider the opposite : master is the
> >>         stable released
> >>         >> version and a branch for development . I already had
> >>         confused people
> >>         >> downloading KC server and cloning the QuickStarts and
> >>         expecting it to work.
> >>         >> But tbh I do not have a string opinion on that.
> >>         >> Le jeu. 18 mai 2017 à 18:57, Bruno Oliveira
> >>         <bruno at abstractj.org <mailto:bruno at abstractj.org>> a
> >>         >> écrit :
> >>         >>
> >>         >>> While working today on the fix of some quickstarts. I'm
> >>         >>> considering to create a separated branch only for stable
> >>         versions of the
> >>         >>> quickstarts.
> >>         >>>
> >>         >>> In this way 'master' would be used only for development
> >>         based on the
> >>         >>> latest bits from Keycloak repo. And 3.1.x, to the latest
> >>         stable
> >>         >>> release on Maven central.
> >>         >>>
> >>         >>> Does it make any sense?
> >>         >>>
> >>         >>> --
> >>         >>>
> >>         >>> abstractj
> >>         >>>
> >>         >> _______________________________________________
> >>         >>> keycloak-dev mailing list
> >>         >>> keycloak-dev at lists.jboss.org
> >>         <mailto:keycloak-dev at lists.jboss.org>
> >>         >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >>         <https://lists.jboss.org/mailman/listinfo/keycloak-dev>
> >>         >>>
> >>         > _______________________________________________
> >>         > keycloak-dev mailing list
> >>         > keycloak-dev at lists.jboss.org
> >>         <mailto:keycloak-dev at lists.jboss.org>
> >>         > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >>         <https://lists.jboss.org/mailman/listinfo/keycloak-dev>
> >>
> >>         _______________________________________________
> >>         keycloak-dev mailing list
> >>         keycloak-dev at lists.jboss.org
> >>         <mailto:keycloak-dev at lists.jboss.org>
> >>         https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >>         <https://lists.jboss.org/mailman/listinfo/keycloak-dev>
> >>
> >>
> >
> >
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev


More information about the keycloak-dev mailing list