Changeset View
Changeset View
Standalone View
Standalone View
docker/README.md
Show First 20 Lines • Show All 427 Lines • ▼ Show 20 Lines | |||||
This example shows the simplest case of the `swh-objstorage` package: | This example shows the simplest case of the `swh-objstorage` package: | ||||
you just have to mount it in the container in `/src` and the | you just have to mount it in the container in `/src` and the | ||||
entrypoint will ensure every swh-* package found in `/src/` is | entrypoint will ensure every swh-* package found in `/src/` is | ||||
installed (using `pip install -e` so you can easily hack your | installed (using `pip install -e` so you can easily hack your | ||||
code). If the application you play with has autoreload support, there | code). If the application you play with has autoreload support, there | ||||
is no need to restart the impacted container.) | is no need to restart the impacted container.) | ||||
Note: if the docker fails to start when using local sources for one or more swh | |||||
package, it's most probably due to permission problems on cache files. For | |||||
example, if you have executed tests locally (using pytest or tox), you have | |||||
cache files (__pycache__ etc.) that will prevent `pip install` from working | |||||
within the docker. | |||||
The solution is to clean these files and directories before trying to spawn the | |||||
docker. | |||||
``` | |||||
~/swh-environment$ find . -type d -name __pycache__ -exec rm -rf {} \; | |||||
~/swh-environment$ find . -type d -name .tox -exec rm -rf {} \; | |||||
~/swh-environment$ find . -type d -name .hypothesis -exec rm -rf {} \; | |||||
``` | |||||
### Using locally installed swh tools with docker | ### Using locally installed swh tools with docker | ||||
In all examples above, we have executed swh commands from within a running | In all examples above, we have executed swh commands from within a running | ||||
container. Now we also have these swh commands locally available in our virtual | container. Now we also have these swh commands locally available in our virtual | ||||
env, we can use them to interact with swh services running in docker | env, we can use them to interact with swh services running in docker | ||||
containers. | containers. | ||||
▲ Show 20 Lines • Show All 54 Lines • ▼ Show 20 Lines | |||||
esac | esac | ||||
eval "$(_SWH_COMPLETE=$autocomplete_cmd swh)" | eval "$(_SWH_COMPLETE=$autocomplete_cmd swh)" | ||||
export SWH_SCHEDULER_URL=http://127.0.0.1:5008/ | export SWH_SCHEDULER_URL=http://127.0.0.1:5008/ | ||||
export CELERY_BROKER_URL=amqp://127.0.0.1:5072/ | export CELERY_BROKER_URL=amqp://127.0.0.1:5072/ | ||||
export COMPOSE_FILE=~/swh-environment/docker/docker-compose.yml:~/swh-environment/docker/docker-compose.override.yml | export COMPOSE_FILE=~/swh-environment/docker/docker-compose.yml:~/swh-environment/docker/docker-compose.override.yml | ||||
alias doco=docker-compose | alias doco=docker-compose | ||||
function swhclean { | |||||
find ~/swh-environment -type d -name __pycache__ -exec rm -rf {} \; | |||||
find ~/swh-environment -type d -name .tox -exec rm -rf {} \; | |||||
find ~/swh-environment -type d -name .hypothesis -exec rm -rf {} \; | |||||
} | |||||
EOF | EOF | ||||
``` | ``` | ||||
This postactivate script does: | This postactivate script does: | ||||
- install a shell completion handler for the swh-scheduler command, | - install a shell completion handler for the swh-scheduler command, | ||||
- preset a bunch of environment variables | - preset a bunch of environment variables | ||||
- `SWH_SCHEDULER_URL` so that you can just run `swh scheduler` against the | - `SWH_SCHEDULER_URL` so that you can just run `swh scheduler` against the | ||||
scheduler API instance running in docker, without having to specify the | scheduler API instance running in docker, without having to specify the | ||||
endpoint URL, | endpoint URL, | ||||
- `CELERY_BROKER` so you can execute the `celery` tool (without cli options) | - `CELERY_BROKER` so you can execute the `celery` tool (without cli options) | ||||
against the rabbitmq server running in the docker environment, | against the rabbitmq server running in the docker environment, | ||||
- `COMPOSE_FILE` so you can run `docker-compose` from everywhere, | - `COMPOSE_FILE` so you can run `docker-compose` from everywhere, | ||||
- create an alias `doco` for `docker-compose` because this is way too | - create an alias `doco` for `docker-compose` because this is way too | ||||
long to type, | long to type, | ||||
- add a `swhclean` shell function to clean your source directories so that | |||||
there is no conflict with docker containers using local swh repositories (see | |||||
below). This will delete any `.tox`, `__pycache__` and `.hypothesis` | |||||
directory found in your swh-environment directory. | |||||
So now you can easily: | So now you can easily: | ||||
* Start the SWH platform: | * Start the SWH platform: | ||||
``` | ``` | ||||
(swh) ~/swh-environment$ doco up -d | (swh) ~/swh-environment$ doco up -d | ||||
[...] | [...] | ||||
``` | ``` | ||||
▲ Show 20 Lines • Show All 139 Lines • Show Last 20 Lines |