Rename ckan.ini to production.ini

SergK · Sergiy Kulanov · commit 13c7fe56327e · 2017-11-29T16:59:23.000+02:00
Fixes: ckan#3776
diff --git a/Dockerfile b/Dockerfile
@@ -55,4 +55,4 @@ ENTRYPOINT ["/ckan-entrypoint.sh"]
 USER ckan
 EXPOSE 5000
 
-CMD ["ckan-paster","serve","/etc/ckan/ckan.ini"]
+CMD ["ckan-paster","serve","/etc/ckan/production.ini"]
diff --git a/contrib/docker/apache.wsgi b/contrib/docker/apache.wsgi
@@ -4,7 +4,7 @@ activate_this = os.path.join(ckan_home, 'bin/activate_this.py')
 execfile(activate_this, dict(__file__=activate_this))
 
 from paste.deploy import loadapp
-config_filepath = os.path.join(os.path.dirname(os.path.abspath(__file__)), 'ckan.ini')
+config_filepath = os.path.join(os.path.dirname(os.path.abspath(__file__)), 'production.ini')
 from paste.script.util.logging_config import fileConfig
 fileConfig(config_filepath)
 application = loadapp('config:%s' % config_filepath)
diff --git a/contrib/docker/ckan-entrypoint.sh b/contrib/docker/ckan-entrypoint.sh
@@ -11,7 +11,7 @@ set -e
 # URL for datapusher (required unless linked to a container called 'datapusher')
 : ${CKAN_DATAPUSHER_URL:=}
 
-CONFIG="${CKAN_CONFIG}/ckan.ini"
+CONFIG="${CKAN_CONFIG}/production.ini"
 
 abort () {
   echo "$@" >&2
@@ -62,6 +62,5 @@ if [ -z "$CKAN_DATAPUSHER_URL" ]; then
 fi
 
 set_environment
-ckan-paster --plugin=ckan db init -c "${CKAN_CONFIG}/ckan.ini"
+ckan-paster --plugin=ckan db init -c "${CKAN_CONFIG}/production.ini"
 exec "$@"
-
diff --git a/contrib/docker/my_init.d/50_configure b/contrib/docker/my_init.d/50_configure
@@ -10,7 +10,7 @@
 
 set -eu
 
-CONFIG="${CKAN_CONFIG}/ckan.ini"
+CONFIG="${CKAN_CONFIG}/production.ini"
 
 abort () {
   echo "$@" >&2
diff --git a/contrib/docker/my_init.d/70_initdb b/contrib/docker/my_init.d/70_initdb
@@ -1,4 +1,4 @@
 #!/bin/sh
 set -eu
 
-"$CKAN_HOME"/bin/paster --plugin=ckan db init -c "${CKAN_CONFIG}/ckan.ini"
+"$CKAN_HOME"/bin/paster --plugin=ckan db init -c "${CKAN_CONFIG}/production.ini"
diff --git a/doc/maintaining/installing/install-from-docker-compose.rst b/doc/maintaining/installing/install-from-docker-compose.rst
@@ -131,7 +131,7 @@ There should be four named Docker volumes (``docker volume ls | grep docker``).
 prefixed with the Docker Compose project name (default: ``docker`` or value of host environment
 variable ``COMPOSE_PROJECT_NAME``.)
 
-* ``docker_ckan_config``: home of ckan.ini
+* ``docker_ckan_config``: home of production.ini
 * ``docker_ckan_home``: home of ckan venv and source, later also additional CKAN extensions
 * ``docker_ckan_storage``: home of CKAN's filestore (resource files)
 * ``docker_pg_data``: home of the database files for CKAN's default and datastore databases
@@ -167,14 +167,14 @@ against the database and import / export files from ``$VOL_CKAN_HOME``.
 3. Datastore and datapusher
 ---------------------------
 To enable the datastore, the datastore database and database users have to be created before
-enabling the datastore and datapusher settings in the ``ckan.ini``.
+enabling the datastore and datapusher settings in the ``production.ini``.
 
 a. Create and configure datastore database
 
 With running CKAN containers, execute the built-in setup scripts against the ``db`` container::
 
     docker exec -it db psql -U ckan -f 00_create_datastore.sql
-    docker exec ckan /usr/local/bin/ckan-paster --plugin=ckan datastore set-permissions -c /etc/ckan/ckan.ini | docker exec -i db psql -U ckan
+    docker exec ckan /usr/local/bin/ckan-paster --plugin=ckan datastore set-permissions -c /etc/ckan/production.ini | docker exec -i db psql -U ckan
 
 The first script will create the datastore database and the datastore readonly user in the ``db``
 container. The second script is the output of ``paster ckan set-permissions`` - however,
@@ -189,13 +189,13 @@ The effect of these scripts is persisted in the named volume ``docker_pg_data``.
     Hard-coding the database table and usernames allows to prepare the set-permissions SQL script,
     while not exposing sensitive information to the world outside the Docker host environment.
 
-After this step, the datastore database is ready to be enabled in the ``ckan.ini``.
+After this step, the datastore database is ready to be enabled in the ``production.ini``.
 
-b. Enable datastore and datapusher in ``ckan.ini``
+b. Enable datastore and datapusher in ``production.ini``
 
-Edit the ``ckan.ini`` (note: requires sudo)::
+Edit the ``production.ini`` (note: requires sudo)::
 
-    sudo vim $VOL_CKAN_CONFIG/ckan.ini
+    sudo vim $VOL_CKAN_CONFIG/production.ini
 
 Add ``datastore datapusher`` to ``ckan.plugins`` and enable the datapusher option
 ``ckan.datapusher.formats``.
@@ -209,7 +209,7 @@ The remaining settings required for datastore and datapusher are already taken c
   ``ckan.datastore.read_url = postgresql://datastore:DATASTORE_READONLY_PASSWORD@db/datastore``
   are provided by ``docker-compose.yml``.
 
-Restart the ``ckan`` container to apply changes to the ``ckan.ini``::
+Restart the ``ckan`` container to apply changes to the ``production.ini``::
 
     docker-compose restart ckan
 
@@ -222,15 +222,15 @@ Now the datastore API should return content when visiting::
 -------------------------
 With all images up and running, create the CKAN admin user (johndoe in this example)::
 
-    docker exec -it ckan /usr/local/bin/ckan-paster --plugin=ckan sysadmin -c /etc/ckan/ckan.ini add johndoe
+    docker exec -it ckan /usr/local/bin/ckan-paster --plugin=ckan sysadmin -c /etc/ckan/production.ini add johndoe
 
 Now you should be able to login to the new, empty CKAN.
 The admin user's API key will be instrumental in tranferring data from other instances.
 
 ---------------
 5. Migrate data
 ---------------
-This section illustrates the data migration from an existing CKAN instance ``SOURCE_CKAN`` 
+This section illustrates the data migration from an existing CKAN instance ``SOURCE_CKAN``
 into our new Docker Compose CKAN instance assuming direct (ssh) access to ``SOURCE_CKAN``.
 
 a. Transfer resource files
@@ -279,17 +279,17 @@ d. Rebuild search index
 
 Trigger a Solr index rebuild::
 
-    docker exec -it ckan /usr/local/bin/ckan-paster --plugin=ckan search-index rebuild -c /etc/ckan/ckan.ini
+    docker exec -it ckan /usr/local/bin/ckan-paster --plugin=ckan search-index rebuild -c /etc/ckan/production.ini
 
 -----------------
 6. Add extensions
 -----------------
 There are two scenarios to add extensions:
 
 * Maintainers of production instances need extensions to be part of the ``ckan`` image and an
-  easy way to enable them in the ``ckan.ini``.
+  easy way to enable them in the ``production.ini``.
   Automating the installation of existing extensions (without needing to change their source)
-  requires customizing CKAN's ``Dockerfile`` and scripted post-processing of the ``ckan.ini``.
+  requires customizing CKAN's ``Dockerfile`` and scripted post-processing of the ``production.ini``.
 * Developers need to read, modify and use version control on the extensions' source. This adds
   additional steps to the maintainers' workflow.
 
@@ -302,7 +302,7 @@ For maintainers, the process is in summary:
 a. Download and install extension from inside ``ckan`` container into ``docker_ckan_home`` volume
 
 The process is very similar to installing extensions in a source install. The only difference is
-that the installation steps will happen inside the running container, and they will use the 
+that the installation steps will happen inside the running container, and they will use the
 virtualenv created inside the ckan image by CKAN's Dockerfile.
 
 The downloaded and installed files will be persisted in the named volume ``docker_ckan_home``.
@@ -352,11 +352,11 @@ E.g., `ckanext-spatial <https://github.com/ckan/ckanext-spatial.git>`_::
 
     # On the host
     docker exec -it db psql -U ckan -f 20_postgis_permissions.sql
-    docker exec -it ckan /usr/local/bin/ckan-paster --plugin=ckanext-spatial spatial initdb -c /etc/ckan/ckan.ini
+    docker exec -it ckan /usr/local/bin/ckan-paster --plugin=ckanext-spatial spatial initdb -c /etc/ckan/production.ini
 
-    sudo vim $VOL_CKAN_CONFIG/ckan.ini
+    sudo vim $VOL_CKAN_CONFIG/production.ini
 
-    # Inside ckan.ini, add to [plugins]:
+    # Inside production.ini, add to [plugins]:
     spatial_metadata spatial_query
 
     ckanext.spatial.search_backend = solr
@@ -365,9 +365,9 @@ b. Modify CKAN config
 
 Follow the respective extension's instructions to set CKAN config variables::
 
-    sudo vim $VOL_CKAN_CONFIG/ckan.ini
+    sudo vim $VOL_CKAN_CONFIG/production.ini
 
-.. todo:: Demonstrate how to set ``ckan.ini`` settings from environment variables using
+.. todo:: Demonstrate how to set ``production.ini`` settings from environment variables using
    ``ckanext-envvars``.
 
 c. Reload and debug
@@ -408,16 +408,16 @@ Option 1: Accessing the source from inside the container::
     # in extension folder:
     python setup.py install
     exit
-    # ... edit extension settings in ckan.ini and restart ckan container
-    sudo vim $VOL_CKAN_CONFIG/ckan.ini
+    # ... edit extension settings in production.ini and restart ckan container
+    sudo vim $VOL_CKAN_CONFIG/production.ini
     docker-compose restart ckan
 
 Option 2: Accessing the source from outside the container using ``sudo``::
 
-    sudo vim $VOL_CKAN_CONFIG/ckan.ini
+    sudo vim $VOL_CKAN_CONFIG/production.ini
     sudo vim $VOL_CKAN_HOME/venv/src/ckanext-datawagovautheme/ckanext/datawagovautheme/templates/package/search.html
 
-Option 3:: The Ubuntu package ``bindfs`` makes the write-protected volumes accessible to a system
+Option 3: The Ubuntu package ``bindfs`` makes the write-protected volumes accessible to a system
 user::
 
     sudo apt-get install bindfs
@@ -436,7 +436,7 @@ user::
 Changes in HTML templates and CSS will be visible right away.
 For changes in code, we'll need to unmount the directory, change ownership back to the ``ckan``
 user, and follow the previous steps to ``python setup.py install`` and
-``pip install -r requirements.txt`` from within the running container, modify the ``ckan.ini``
+``pip install -r requirements.txt`` from within the running container, modify the ``production.ini``
 and restart the container::
 
     sudo umount ~/VOL_CKAN_HOME
@@ -467,10 +467,10 @@ Variable substitution propagates as follows:
   (when building the images) and / or as run time variables (when running the containers).
 * ``ckan-entrypoint.sh`` has access to all run time variables of the ``ckan`` service.
 * ``ckan-entrypoint.sh`` injects environment variables (e.g. ``CKAN_SQLALCHEMY_URL``) into the
-  running ``ckan`` container, overriding the CKAN config variables from ``ckan.ini``.
+  running ``ckan`` container, overriding the CKAN config variables from ``production.ini``.
 
 See :doc:`/maintaining/configuration` for a list of environment variables
-(e.g. ``CKAN_SQLALCHEMY_URL``) which CKAN will accept to override ``ckan.ini``.
+(e.g. ``CKAN_SQLALCHEMY_URL``) which CKAN will accept to override ``production.ini``.
 
 After adding new or changing existing ``.env`` variables, locally built images and volumes may
 need to be dropped and rebuilt. Otherwise, docker will re-use cached images with old or missing
@@ -508,4 +508,3 @@ A possible path towards a production-ready environment is:
 * Transfer production data into the new server as described above using volume orchestration
   tools or transferring files directly.
 * Bonus: contribute a write-up of working production setups to the CKAN documentation.
-
