Many users visit the repo primarily to quickly deploy and test a local instance of astrometry.net's web APIs or web interfaces. While it's possible to follow the detailed instructions in the net folder, having a docker file would significantly simplify this process and make the repo more accessible. We already have a set of docker files, but there's still room for improvement.
The documentation is not detailed enough.
All the code is fetched fresh from GitHub, which makes any local changes ineffective. We'll discuss this more below.
By using --net=host, the container shares the same web interface with the host. This isn't very secure and can sometimes lead to unexpected behavior. For instance, in the container, localhost refers to the host machine, not the container.
Some components are outdated and require manual intervention to function. For example, the log directory wasn't created, which resulted in an error as it couldn't write to the log.
The web service deployment is complex, involving two separate servers - one for computation and another for the Django-based web server.
This PR aims to address the issues mentioned above, except the last one, which needs further guidance from the author(s) and the community. Before we delve into the details, I'd like to discuss the second issue as it involves a fundamental design decision.
The Dockerfile's core function is to pull the code, the configuration, and the data. While pulling from GitHub ensures the code is always the latest version, it also has several drawbacks:
Any local changes won't be reflected in the container.
The configuration process has to occur within the container, which risks data loss and hinders reusability.
The index downloading and building process also needs to happen in the container, which is prone to data loss.
Considering that the Docker file is located within the repository, it implies that the user is expected to already have the repository on hand. After weighing the pros and cons, this PR proposes an alternative to the current solution. The suggestion is to directly copy the local code and configurations to the container. The only exception is the data, which could be quite large. To save image building time and enhance reusability across multiple containers when needed, we map it to the container as a volume.
dstndstn
commented
5 months ago
Many users visit the repo primarily to quickly deploy and test a local instance of astrometry.net's web APIs or web interfaces. While it's possible to follow the detailed instructions in the
netfolder, having a docker file would significantly simplify this process and make the repo more accessible. We already have a set of docker files, but there's still room for improvement.--net=host, the container shares the same web interface with the host. This isn't very secure and can sometimes lead to unexpected behavior. For instance, in the container,localhostrefers to the host machine, not the container.This PR aims to address the issues mentioned above, except the last one, which needs further guidance from the author(s) and the community. Before we delve into the details, I'd like to discuss the second issue as it involves a fundamental design decision.
The Dockerfile's core function is to pull the code, the configuration, and the data. While pulling from GitHub ensures the code is always the latest version, it also has several drawbacks:
Considering that the Docker file is located within the repository, it implies that the user is expected to already have the repository on hand. After weighing the pros and cons, this PR proposes an alternative to the current solution. The suggestion is to directly copy the local code and configurations to the container. The only exception is the data, which could be quite large. To save image building time and enhance reusability across multiple containers when needed, we map it to the container as a volume.
I'm open to any suggestions on the PR.