mirror/keycloak
1
0
Fork 0
mirror of https://github.com/keycloak/keycloak.git synced 2026-01-06 06:49:53 -06:00
Code Issues Packages Projects Releases Wiki Activity

Update installation locations

Browse Source 
Closes #34855

Signed-off-by: AndyMunro <amunro@redhat.com>
Signed-off-by: Alexander Schwartz <aschwart@redhat.com>
Co-authored-by: Alexander Schwartz <aschwart@redhat.com>
This commit is contained in:
andymunro
2024-11-12 09:10:32 -05:00
committed by GitHub
parent 6a46667c82
commit 3ca3a4ad34
2 changed files with 14 additions and 7 deletions
Download Patch File Download Diff File Expand all files Collapse all files

19
docs/guides/server/directory-structure.adoc
View File

@@ -1,5 +1,6 @@
<#import "/templates/guide.adoc" as tmpl>
<#import "/templates/links.adoc" as links>
<#import "/templates/profile.adoc" as profile>
<@tmpl.guide
title="Directory Structure"
@@ -10,9 +11,15 @@ includedOptions="">
If you are installing from a zip file then by default there will be an install root directory of `{archivebasename}-{version}`, which can be created anywhere you choose on your filesystem.
`/opt/keycloak` is the root install location for the server in all containerized usage shown for {project_name} including <@links.server id="containers"/>, <@links.gettingstarted id="getting-started-docker"/>, <@links.gettingstarted id="getting-started-podman"/>, <@links.gettingstarted id="getting-started-kubernetes"/>, and <@links.gettingstarted id="getting-started-openshift"/>.
<@profile.ifCommunity>
`/opt/keycloak` is the root install location for the server in all containerized usage shown for {project_name} including <@links.server id="containers"/>, <@links.gettingstarted id="getting-started-docker"/>, <@links.gettingstarted id="getting-started-podman"/>, <@links.gettingstarted id="getting-started-kube"/>, and <@links.gettingstarted id="getting-started-openshift"/>.
</@profile.ifCommunity>
NOTE: in the rest of documentation relative paths are understood to be relative to the install root - e.g. `conf/file.xml` means `<install root>/conf/file.xml`
<@profile.ifProduct>
`/opt/keycloak` is the root install location for the server in all containerized usage shown for {project_name}.
</@profile.ifProduct>
NOTE: In the rest of the documentation, relative paths are understood to be relative to the install root - for example, `conf/file.xml` means `<install root>/conf/file.xml`
== Directory Structure
@@ -20,12 +27,12 @@ Under the {project_name} install root there exists a number of folders:
* *bin/* - contains all the shell scripts for the server, including `kc.sh|bat`, `kcadm.sh|bat`, and `kcreg.sh|bat`
** *client/* - used internally
* *conf/* - directory used for configuration files, including `keycloak.conf` - see <@links.server id="configuration"/>. Many options for specifying a configuration file expect paths relative to this directory.
** *truststores/* - default path used by the `truststore-paths` option - see <@links.server id="keycloak-truststore"/>
* *data/* - directory for the server to store runtime information, such as transaction logs
* *conf/* - directory used for configuration files, including `keycloak.conf` - see <@links.server id="configuration"/>. Many options for specifying a configuration file expect paths relative to this directory.
** *truststores/* - default path used by the `truststore-paths` option - see <@links.server id="keycloak-truststore"/>
* *data/* - directory for the server to store runtime information, such as transaction logs
** *logs/* - default directory for file logging - see <@links.server id="logging"/>
* *lib/* - used internally
* *providers/* - directory for user provided dependencies - see <@links.server id="configuration-provider"/> for extending the server and <@links.server id="db"/> for an example of add a JDBC driver.
* *providers/* - directory for user provided dependencies - see <@links.server id="configuration-provider"/> for extending the server and <@links.server id="db"/> for an example of add a JDBC driver.
* *themes/* - directory for customizations to the Admin Console - see https://www.keycloak.org/docs/latest/server_development/#_themes[Developing Themes]
</@tmpl.guide>

2
docs/guides/server/reverseproxy.adoc
View File

@@ -82,7 +82,7 @@ It is beneficial if particular session entity is always available locally, which
From this point, it is beneficial if load balancer forwards all the next requests to the node2 as this is the node, who is owner of the authentication session with ID 123 and hence Infinispan can lookup this session locally. After authentication is finished, the authentication session is converted to user session, which will be also saved on node2 because it has same ID 123 .
The sticky session is not mandatory for the cluster setup, however it is good for performance for the reasons mentioned above. You need to configure your loadbalancer to sticky over the AUTH_SESSION_ID cookie. How exactly do this is dependent on your loadbalancer.
The sticky session is not mandatory for the cluster setup, however it is good for performance for the reasons mentioned above. You need to configure your loadbalancer to stick over the AUTH_SESSION_ID cookie. The appropriate procedure to make this change depends on your loadbalancer.
If your proxy supports session affinity without processing cookies from backend nodes, you should set the `spi-sticky-session-encoder-infinispan-should-attach-route` option
to `false` in order to avoid attaching the node to cookies and just rely on the reverse proxy capabilities.