SkyPortal can be deployed either with or without using Docker. Without Docker, all services (such as the database) need to be running locally, as described in setup.
More commonly, production deployment will use Docker images. Here, we discuss how to deploy via docker-compose, but much of the same information applies when using Kubernetes, for which we have an example deployment.
The first step is to obtain the images to launch. We deploy SkyPortal images to Docker Hub from time to time, which you can fetch using:
docker pull skyportal/web
Otherwise, you may build the images from scratch:
make docker-local
Next, we deploy two containers: web
(the SkyPortal application) and
db
(the PostgreSQL server). The database is stored and persisted in a local
docker volume called skyportal_dbdata
(see docker volume ls
).
docker-compose up -d
Once both services are up and running, you may browse to SkyPortal at http://localhost:9000
.
You can see which containers are running with docker-compose ps
.
Inspect the logs for the running containers using:
docker-compose logs web
docker-compose logs db
(Or, follow the logs with docker-compose logs -f db
.)
Note that by default, the SkyPortal image will run the application in production (make run_production
).
The key behavior to note when running production mode is that the application will not create any database tables automatically (to avoid messing with production data). This means that the very first time you spin up SkyPortal using containers, the skyportal_dbdata
volume will only have an empty database. You will need to set up the database tables manually. The easiest way to do this would be to run:
docker exec skyportal_web_1 bash -c 'source /skyportal_env/bin/activate && FLAGS="--create_tables --config=config.yaml" make load_demo_data'
This will also load in some test data to play with.
You may stop both containers using:
docker-compose stop
Or stop and remove them using:
docker-compose down
This does not affect data, which lives in the ./dbdata
directory.