[
https://issues.apache.org/jira/browse/RANGER-5554?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Abhishek Kumar updated RANGER-5554:
-----------------------------------
Description:
Ranger Admin startup currently depends on tarball-era installation behavior
such as setup.sh, install.properties, and implicit filesystem preparation. This
makes the container startup path not well aligned with Kubernetes-native
deployment patterns.
This work refactors Ranger Admin container bootstrap so that the service can
start, initialize its schema, and create services using container-mounted
runtime configuration (volume mounted) and helper scripts (baked into the
image), without relying on installation-time setup flows from the tarball.
h3. Scope
* Replace {{{}setup.sh{}}}-style initialization assumptions with explicit
runtime bootstrap logic in container entrypoint flow.
* Make {{ranger-admin-site.xml}} the primary runtime configuration source for
Ranger Admin startup.
* Support mounting admin config artifacts into {{/opt/ranger/admin/configs}}
and copying them into generated runtime conf locations during startup.
* Ensure DB bootstrap and schema initialization run correctly in container
startup without {{{}install.properties{}}}-driven setup flow.
* Support DB flavors: postgres, mysql and oracle.
* Update Dockerfile.ranger to include all DB connectors (at build time) and
use the one indicated by RANGER_DB_TYPE env variable at runtime.
was:
Ranger Admin startup currently depends on tarball-era installation behavior
such as setup.sh, install.properties, and implicit filesystem preparation. This
makes the container startup path not well aligned with Kubernetes-native
deployment patterns.
This work refactors Ranger Admin container bootstrap so that the service can
start, initialize its schema, and create services using container-mounted
runtime configuration and helper scripts, without relying on installation-time
setup flows from the tarball.
h3. Scope
* Replace {{{}setup.sh{}}}-style initialization assumptions with explicit
runtime bootstrap logic in container entrypoint flow.
* Make {{ranger-admin-site.xml}} the primary runtime configuration source for
Ranger Admin startup.
* Support mounting admin config artifacts into {{/opt/ranger/admin/configs}}
and copying them into generated runtime conf locations during startup.
* Ensure DB bootstrap and schema initialization run correctly in container
startup without {{{}install.properties{}}}-driven setup flow.
* Support DB flavors: postgres, mysql and oracle.
* Update Dockerfile.ranger to include all DB connectors (at build time) and
use the one indicated by RANGER_DB_TYPE env variable at runtime.
> Refactor Ranger Admin docker bootstrap to use runtime XML config only
> ---------------------------------------------------------------------
>
> Key: RANGER-5554
> URL: https://issues.apache.org/jira/browse/RANGER-5554
> Project: Ranger
> Issue Type: Improvement
> Components: docker, Ranger
> Reporter: Abhishek Kumar
> Assignee: Abhishek Kumar
> Priority: Major
> Time Spent: 50m
> Remaining Estimate: 0h
>
> Ranger Admin startup currently depends on tarball-era installation behavior
> such as setup.sh, install.properties, and implicit filesystem preparation.
> This makes the container startup path not well aligned with Kubernetes-native
> deployment patterns.
> This work refactors Ranger Admin container bootstrap so that the service can
> start, initialize its schema, and create services using container-mounted
> runtime configuration (volume mounted) and helper scripts (baked into the
> image), without relying on installation-time setup flows from the tarball.
> h3. Scope
> * Replace {{{}setup.sh{}}}-style initialization assumptions with explicit
> runtime bootstrap logic in container entrypoint flow.
> * Make {{ranger-admin-site.xml}} the primary runtime configuration source
> for Ranger Admin startup.
> * Support mounting admin config artifacts into {{/opt/ranger/admin/configs}}
> and copying them into generated runtime conf locations during startup.
> * Ensure DB bootstrap and schema initialization run correctly in container
> startup without {{{}install.properties{}}}-driven setup flow.
> * Support DB flavors: postgres, mysql and oracle.
> * Update Dockerfile.ranger to include all DB connectors (at build time) and
> use the one indicated by RANGER_DB_TYPE env variable at runtime.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
