I believe nowadays the tech to use for such multiserver setups would
be Docker / OpenShift.
That's good. I like the OpenShift idea especially.
Then, quickstart just becomes:
1) Spin up a pre-configured QuickStart instance of Keycloak on OpenShift
2) Spin up a pre-configured QuickStart instance of WildFly on OpenShift
3) Download the QuickStart app projects
4) Make your changes to QuickStart apps and upload to OpenShift
On May 19, 2017 14:50, "Stan Silvert" <ssilvert(a)redhat.com
<mailto:ssilvert@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(a)redhat.com
<mailto:ssilvert@redhat.com>
> <mailto:ssilvert@redhat.com <mailto:ssilvert@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(a)redhat.com
<mailto:ssilvert@redhat.com>
>> <mailto:ssilvert@redhat.com
<mailto:ssilvert@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(a)redhat.com <mailto:sblanc@redhat.com>
<mailto:sblanc@redhat.com <mailto:sblanc@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(a)abstractj.org <mailto:bruno@abstractj.org>
<mailto:bruno@abstractj.org <mailto:bruno@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(a)lists.jboss.org
<mailto:keycloak-dev@lists.jboss.org>
>> <mailto:keycloak-dev@lists.jboss.org
<mailto:keycloak-dev@lists.jboss.org>>
>> >>>
https://lists.jboss.org/mailman/listinfo/keycloak-dev
<
https://lists.jboss.org/mailman/listinfo/keycloak-dev>
>> <
https://lists.jboss.org/mailman/listinfo/keycloak-dev
<
https://lists.jboss.org/mailman/listinfo/keycloak-dev>>
>> >>>
>> > _______________________________________________
>> > keycloak-dev mailing list
>> > keycloak-dev(a)lists.jboss.org
<mailto:keycloak-dev@lists.jboss.org>
>> <mailto:keycloak-dev@lists.jboss.org
<mailto:keycloak-dev@lists.jboss.org>>
>> >
https://lists.jboss.org/mailman/listinfo/keycloak-dev
<
https://lists.jboss.org/mailman/listinfo/keycloak-dev>
>> <
https://lists.jboss.org/mailman/listinfo/keycloak-dev
<
https://lists.jboss.org/mailman/listinfo/keycloak-dev>>
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev(a)lists.jboss.org <mailto:keycloak-dev@lists.jboss.org>
>> <mailto:keycloak-dev@lists.jboss.org
<mailto:keycloak-dev@lists.jboss.org>>
>>
https://lists.jboss.org/mailman/listinfo/keycloak-dev
<
https://lists.jboss.org/mailman/listinfo/keycloak-dev>
>> <
https://lists.jboss.org/mailman/listinfo/keycloak-dev
<
https://lists.jboss.org/mailman/listinfo/keycloak-dev>>
>>
>>
>
>
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org <mailto:keycloak-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/keycloak-dev
<
https://lists.jboss.org/mailman/listinfo/keycloak-dev>