Add Docker image for Unity Catalog#18
Conversation
…uild folders to gitignore
|
Thank you for this pr. Docker would be great. I am going to play with this thing as soon as I get a chance. |
| as well as provide a convenient way to explore the content of any UC server implementation. | ||
|
|
||
| ### Prerequisites | ||
| - Docker |
There was a problem hiding this comment.
You do have to clone this repo still, so the 2 options has to be under the instructions of cloning the repo.
There was a problem hiding this comment.
You don't need to clone the repo if running the docker run ... command. It will pull the image from Dockerhub and start running straight away.
There was a problem hiding this comment.
Can you elaborate a bit more about this? what will be the full command of docker run ...
If we are adding a completely new way to run these steps, then we need to write down the exact steps that people can copy paste and run and leave nothing to assumption.
And I am not as familiar with Docker as i want to be. I am guessing that this docker run ... command is going to download from dockerhub? who is going to publish docker hub?
| @@ -0,0 +1,32 @@ | |||
| #!/bin/bash | |||
|
|
|||
There was a problem hiding this comment.
Could you add some comments in the file on what does this file do?
| @@ -0,0 +1,32 @@ | |||
| #!/bin/bash | |||
There was a problem hiding this comment.
Does this script have to be in the root of the repo. Keeping th root of the repo uncluttered is better
# Conflicts: # .gitignore # README.md # etc/db/h2db.mv.db
|
Would love to see a docker image for this as well but I'm wondering how |
I was using When this PR is merged, to get the GitHub action to work, someone will have to add in |
|
|
||
| ENV SERVER_PROPERTIES_FILE=/opt/app/etc/conf/server.properties | ||
| ENV SERVER_JOG4J_CONFIGURATION_FILE=/opt/app/etc/conf/server.log4j2.properties | ||
| ENV CLI_JOG4J_CONFIGURATION_FILE=/opt/app/etc/conf/cli.log4j2.properties |
There was a problem hiding this comment.
Where are these ENV variables used? What's the point of assigning them?
| WORKDIR /opt/app | ||
|
|
||
| COPY server/target/unitycatalog-server-assembly.jar unitycatalog-server.jar | ||
| COPY examples/cli/target/unitycatalog-cli-assembly.jar unitycatalog-cli.jar |
There was a problem hiding this comment.
whats the purpose of the CLI jar in docker? we are not running the CLI in docker
|
|
||
| ### Run the UC Server | ||
| ```shell | ||
| docker run -d -i --name unitycatalog -p 8081:8081 unitycatalog/unitycatalog:0.1.0 |
There was a problem hiding this comment.
this docker run step will only work with published versions of the server? like 0.1?
my goal was for these steps to be runnable by anyone with the current unpublished code as soon as they clone this repo
There was a problem hiding this comment.
We could document how to build the container locally, and afterwards also execute it locally.
| @@ -0,0 +1,26 @@ | |||
| #!/bin/bash | |||
There was a problem hiding this comment.
what is the point of this file
| return apiClient; | ||
| } | ||
|
|
||
| private String getLogPropertiesFilePath() { |
There was a problem hiding this comment.
why do we need to define these properties. why not just keep it simple and always load the configurations from /etc/conf?
tdas
left a comment
There was a problem hiding this comment.
Overall, thank you for your attempt to dockerize the whole thing. But there are a lot of changes in this PR that I dont understand the purpose of. could you please bear with me, and answer my questions so that we understand what we are merging and what will be needed to maintain this?
There was a problem hiding this comment.
Is there a reason why this is a separate script, and not part of yaml pipeline file?
Signed-off-by: Peter Flook <[email protected]>
|
+1 Nice to have dockerization version of uc. |
|
+1 |
# Description of changes For this PR I took an alternative approach to #18 and #22 and created a Dockerfile with build and start scripts that require minimal intervention and interaction with the codebase. From the codebase the only change is the .gitignore where I added the .DS_Store which can be helpful in the future for contributors using Mac OS, PR #22 is a great start but maybe oversimplified. PR #18 Has good thought put into it but I wanted to stay close to the recommended way of running Unity Catalog as outlined in the project's README. I tried not to fiddle directly with the jars and use the provided `/bin/start-uc-server` to run the catalog. With this approach the Dockerfile remains focused on building the environment and any changes to how the environment should run can be made in the future inside the `start-uc-server` script rather than the Dockerfile. # Rationale of the PR This pull request introduces a way to run Unity Catalog using Docker containers. It provides a Dockerfile that builds the necessary environment and separate bash scripts for building and starting the catalog. This simplifies the process for users by requiring minimal interaction with the codebase itself. The included README provides detailed instructions on how to use these scripts to build and run the Unity Catalog container. > [!NOTE] > The `README.md` contains two API calls that create an external and an managed table. > These APIs are not working yet because they are not supported by the catalogue yet. Signed-off-by: Jean Boutros <[email protected]> --------- Signed-off-by: Jean Boutros <[email protected]> Co-authored-by: Fokko Driesprong <[email protected]> Co-authored-by: Denny Lee <[email protected]>
|
This duplicates a PR #116 that included Docker functionality |
# Description of changes For this PR I took an alternative approach to unitycatalog#18 and unitycatalog#22 and created a Dockerfile with build and start scripts that require minimal intervention and interaction with the codebase. From the codebase the only change is the .gitignore where I added the .DS_Store which can be helpful in the future for contributors using Mac OS, PR unitycatalog#22 is a great start but maybe oversimplified. PR unitycatalog#18 Has good thought put into it but I wanted to stay close to the recommended way of running Unity Catalog as outlined in the project's README. I tried not to fiddle directly with the jars and use the provided `/bin/start-uc-server` to run the catalog. With this approach the Dockerfile remains focused on building the environment and any changes to how the environment should run can be made in the future inside the `start-uc-server` script rather than the Dockerfile. # Rationale of the PR This pull request introduces a way to run Unity Catalog using Docker containers. It provides a Dockerfile that builds the necessary environment and separate bash scripts for building and starting the catalog. This simplifies the process for users by requiring minimal interaction with the codebase itself. The included README provides detailed instructions on how to use these scripts to build and run the Unity Catalog container. > [!NOTE] > The `README.md` contains two API calls that create an external and an managed table. > These APIs are not working yet because they are not supported by the catalogue yet. Signed-off-by: Jean Boutros <[email protected]> --------- Signed-off-by: Jean Boutros <[email protected]> Co-authored-by: Fokko Driesprong <[email protected]> Co-authored-by: Denny Lee <[email protected]> Signed-off-by: Kevin Wang <[email protected]>
Some small changes are included in this PR to help create a working Docker image for Unity Catalog:
uc-dockerscript for CLI to work straight away on the Docker imageserver.propertiesandlog4j2.propertiesfile pathways to be set via environment variables or system propertiesv's--formatto--outputin the documentation