You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Group environment variables by the corresponding directories (cookiecutter#1295)
* Update generated project's .gitignore
* Post-gen gitignore .env/ and .env
* Fix linesep between gitignored entries
* Persist `.env/**/*` files into cookiecutter-django's VCS
* Rename .env/ to .envs/
* Reference the newly created .envs/**/.* files in local.yml
* Reference the newly created .envs/**/.* files in production.yml
* Delete .env.example
* Refactor post-gen-project.py
Closescookiecutter#1299.
* Implement production-dotenv-files-to-dotenv-file merge script
* Create shared PyCharm Run Configuration for the automation script
* Randomize POSTGRES_PASSWORD in ./envs/(.local|.production)/.postgres
* Default POSTGRES_PASSWORD and POSTGRES_USER to random values
* Fix jinja linebreaks in local.yml
* Spaces in production.yml
* Fix post-merge leftovers & set DJANGO_ADMIN_URL automatically
* Prettify here and there
* Fix FileNotFoundError
* Leave a TODO in post_gen_hook.py
* Introduce keep_local_envs_in_vcs option
* Remove envs when not opted for
* Inline pre_gen_project.py if-condition
* Get rid of PROJECT_DIR_PATH in post_gen_project.py
* Clean up the docs
* Match copyright notices
* Document envs ins and outs
Copy file name to clipboardExpand all lines: README.rst
+2-1Lines changed: 2 additions & 1 deletion
Original file line number
Diff line number
Diff line change
@@ -129,7 +129,7 @@ Pyup brings you automated security and dependency updates used by Google and oth
129
129
Usage
130
130
------
131
131
132
-
Let's pretend you want to create a Django project called "redditclone". Rather than using `startproject`
132
+
Let's pretend you want to create a Django project called "redditclone". Rather than using ``startproject``
133
133
and then editing the results to include your name, email, and various configuration issues that always get forgotten until the worst possible moment, get cookiecutter_ to do all the work.
134
134
135
135
First, get Cookiecutter. Trust me, it's awesome::
@@ -192,6 +192,7 @@ Answer the prompts with your own desired options_. For example::
Copy file name to clipboardExpand all lines: docs/deployment-on-pythonanywhere.rst
+1-1Lines changed: 1 addition & 1 deletion
Original file line number
Diff line number
Diff line change
@@ -83,7 +83,7 @@ Database setup:
83
83
84
84
Go to the PythonAnywhere **Databases tab** and configure your database.
85
85
86
-
* For Postgres, setup your superuser password, then open a Postgres console and run a `CREATE DATABASE my-db-name`. You should probably also set up a specific role and permissions for your app, rather than using the superuser credentials. Make a note of the address and port of your postgres server.
86
+
* For Postgres, setup your superuser password, then open a Postgres console and run a ``CREATE DATABASE my-db-name``. You should probably also set up a specific role and permissions for your app, rather than using the superuser credentials. Make a note of the address and port of your postgres server.
87
87
88
88
* For MySQL, set the password and create a database. More info here: https://help.pythonanywhere.com/pages/UsingMySQL
Postgres is saving its database files to the `postgres_data` volume by default. Change that if you want something else and make sure to make backups since this is not done automatically.
80
80
81
-
Run your app with docker-compose
81
+
Run your app with Docker Compose
82
82
--------------------------------
83
83
84
84
To get started, pull your code from source control (don't forget the `.env` file) and change to your projects root
@@ -94,15 +94,15 @@ Once this is ready, you can run it with::
94
94
95
95
To run a migration, open up a second terminal and run::
96
96
97
-
docker-compose -f production.yml run django python manage.py migrate
97
+
docker-compose -f production.yml run --rm django python manage.py migrate
98
98
99
99
To create a superuser, run::
100
100
101
-
docker-compose -f production.yml run django python manage.py createsuperuser
101
+
docker-compose -f production.yml run --rm django python manage.py createsuperuser
102
102
103
103
If you need a shell, run::
104
104
105
-
docker-compose -f production.yml run django python manage.py shell
105
+
docker-compose -f production.yml run --rm django python manage.py shell
Currently PostgreSQL (``psycopg2`` python package) is not installed inside Docker containers for Windows users, while it is required by the generated Django project. To fix this, add ``psycopg2`` to the list of requirements inside ``requirements/base.txt``::
28
24
@@ -31,23 +27,21 @@ Currently PostgreSQL (``psycopg2`` python package) is not installed inside Docke
31
27
32
28
Doing this will prevent the project from being installed in an Windows-only environment (thus without usage of Docker). If you want to use this project without Docker, make sure to remove ``psycopg2`` from the requirements again.
33
29
30
+
34
31
Build the Stack
35
32
---------------
36
33
37
-
This can take a while, especially the first time you run this particular command
38
-
on your development system::
34
+
This can take a while, especially the first time you run this particular command on your development system::
39
35
40
36
$ docker-compose -f local.yml build
41
37
42
-
If you want to build the production environment you use ``production.yml`` as -f argument (``docker-compose.yml`` or ``docker-compose.yaml`` are the defaults).
38
+
Generally, if you want to emulate production environment use ``production.yml`` instead. And this is true for any other actions you might need to perform: whenever a switch is required, just do it!
43
39
44
-
Boot the System
45
-
---------------
46
40
47
-
This brings up both Django and PostgreSQL.
41
+
Run the Stack
42
+
-------------
48
43
49
-
The first time it is run it might take a while to get started, but subsequent
50
-
runs will occur quickly.
44
+
This brings up both Django and PostgreSQL. The first time it is run it might take a while to get started, but subsequent runs will occur quickly.
51
45
52
46
Open a terminal at the project root and run the following for local development::
53
47
@@ -61,98 +55,108 @@ And then run::
61
55
62
56
$ docker-compose up
63
57
64
-
Running management commands
65
-
~~~~~~~~~~~~~~~~~~~~~~~~~~~
58
+
To run in a detached (background) mode, just::
66
59
67
-
As with any shell command that we wish to run in our container, this is done
68
-
using the ``docker-compose -f local.yml run`` command.
60
+
$ docker-compose up -d
69
61
70
-
To migrate your app and to create a superuser, run::
71
62
72
-
$ docker-compose -f local.yml run django python manage.py migrate
73
-
$ docker-compose -f local.yml run django python manage.py createsuperuser
63
+
Execute Management Commands
64
+
---------------------------
74
65
75
-
Here we specify the ``django`` container as the location to run our management commands.
66
+
As with any shell command that we wish to run in our container, this is done using the ``docker-compose -f local.yml run --rm`` command: ::
76
67
77
-
Add your Docker development server IP
78
-
-------------------------------------
68
+
$ docker-compose -f local.yml run --rm django python manage.py migrate
69
+
$ docker-compose -f local.yml run --rm django python manage.py createsuperuser
79
70
80
-
When ``DEBUG`` is set to `True`, the host is validated against ``['localhost', '127.0.0.1', '[::1]']``. This is adequate when running a ``virtualenv``. For Docker, in the ``config.settings.local``, add your host development server IP to ``INTERNAL_IPS`` or ``ALLOWED_HOSTS`` if the variable exists.
71
+
Here, ``django`` is the target service we are executing the commands against.
81
72
82
-
Production Mode
83
-
~~~~~~~~~~~~~~~
84
73
85
-
Instead of using `local.yml`, you would use `production.yml`.
74
+
(Optionally) Designate your Docker Development Server IP
When ``DEBUG`` is set to ``True``, the host is validated against ``['localhost', '127.0.0.1', '[::1]']``. This is adequate when running a ``virtualenv``. For Docker, in the ``config.settings.local``, add your host development server IP to ``INTERNAL_IPS`` or ``ALLOWED_HOSTS`` if the variable exists.
89
78
90
-
Make a machine the active unit
91
-
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
92
79
93
-
This tells our computer that all future commands are specifically for the dev1 machine.
94
-
Using the ``eval`` command we can switch machines as needed.
80
+
Configuring the Environment
81
+
---------------------------
95
82
96
-
::
83
+
This is the excerpt from your project's ``local.yml``: ::
If you want to run the stack in detached mode (in the background), use the ``-d`` argument:
97
+
# ...
104
98
105
-
::
99
+
The most important thing for us here now is ``env_file`` section enlisting ``./.envs/.local/.postgres``. Generally, the stack's behavior is governed by a number of environment variables (`env(s)`, for short) residing in ``envs/``, for instance, this is what we generate for you: ::
106
100
107
-
$ docker-compose -f local.yml up -d
101
+
.envs
102
+
├── .local
103
+
│ ├── .django
104
+
│ └── .postgres
105
+
└── .production
106
+
├── .caddy
107
+
├── .django
108
+
└── .postgres
108
109
109
-
Debugging
110
-
~~~~~~~~~~~~~
110
+
By convention, for any service ``sI`` in environment ``e`` (you know ``someenv`` is an environment when there is a ``someenv.yml`` file in the project root), given ``sI`` requires configuration, a ``.envs/.e/.sI`` `service configuration` file exists.
111
111
112
-
ipdb
113
-
"""""
112
+
Consider the aforementioned ``.envs/.local/.postgres``: ::
114
113
115
-
If you are using the following within your code to debug:
The two envs we are presented with here are ``POSTGRES_USER``, and ``POSTGRES_PASSWORD`` (by the way, their values have also been generated for you). You might have figured out already where these definitions will end up; it's all the same with ``django`` and ``caddy`` service container envs.
118
120
119
-
import ipdb; ipdb.set_trace()
120
121
121
-
Then you may need to run the following for it to work as desired:
122
+
Tips & Tricks
123
+
-------------
124
+
125
+
Activate a Docker Machine
126
+
~~~~~~~~~~~~~~~~~~~~~~~~~
122
127
123
-
::
128
+
This tells our computer that all future commands are specifically for the dev1 machine. Using the ``eval`` command we can switch machines as needed.::
124
129
125
-
$ docker-compose -f local.yml run --service-ports django
130
+
$ eval "$(docker-machine env dev1)"
126
131
132
+
Debugging
133
+
~~~~~~~~~
127
134
128
-
django-debug-toolbar
129
-
""""""""""""""""""""
135
+
ipdb
136
+
"""""
137
+
138
+
If you are using the following within your code to debug: ::
130
139
131
-
In order for django-debug-toolbar to work with docker you need to add your docker-machine ip address to ``INTERNAL_IPS`` in ``local.py``
140
+
import ipdb; ipdb.set_trace()
132
141
142
+
Then you may need to run the following for it to work as desired: ::
133
143
134
-
.. May be a better place to put this, as it is not Docker specific.
144
+
$ docker-compose -f local.yml run --rm --service-ports django
135
145
136
-
You may need to add the following to your css in order for the django-debug-toolbar to be visible (this applies whether Docker is being used or not):
137
146
138
-
.. code-block:: css
147
+
django-debug-toolbar
148
+
""""""""""""""""""""
139
149
140
-
/* Override Bootstrap 4 styling on Django Debug Toolbar */
141
-
#djDebug[hidden], #djDebug [hidden] {
142
-
display: block!important;
143
-
}
150
+
In order for ``django-debug-toolbar`` to work designate your Docker Machine IP with ``INTERNAL_IPS`` in ``local.py``.
144
151
145
-
#djDebug [hidden][style='display: none;'] {
146
-
display: none!important;
147
-
}
148
152
153
+
Mailhog
154
+
~~~~~~~
149
155
150
-
Using the Mailhog Docker Container
151
-
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
156
+
When developing locally you can go with MailHog_ for email testing provided ``use_mailhog`` was set to ``y`` on setup. To proceed,
152
157
153
-
In development you can (optionally) use MailHog_ for email testing. If you selected `use_docker`, MailHog is added as a Docker container. To use MailHog:
158
+
#. make sure ``mailhog`` container is up and running;
154
159
155
-
1. Make sure, that ``mailhog`` docker container is up and running
156
-
2. Open your browser and go to ``http://127.0.0.1:8025``
Copy file name to clipboardExpand all lines: docs/docker-postgres-backups.rst
+4-4Lines changed: 4 additions & 4 deletions
Original file line number
Diff line number
Diff line change
@@ -2,7 +2,7 @@
2
2
Database Backups with Docker
3
3
============================
4
4
5
-
The database has to be running to create/restore a backup. These examples show local examples. If you want to use it on a remote server, remove ``-f local.yml`` from each example.
5
+
The database has to be running to create/restore a backup. These examples show local examples. If you want to use it on a remote server, use ``-f production.yml`` instead.
6
6
7
7
Running Backups
8
8
================
@@ -11,17 +11,17 @@ Run the app with `docker-compose -f local.yml up`.
11
11
12
12
To create a backup, run::
13
13
14
-
docker-compose -f local.yml run postgres backup
14
+
docker-compose -f local.yml run --rm postgres backup
15
15
16
16
17
17
To list backups, run::
18
18
19
-
docker-compose -f local.yml run postgres list-backups
19
+
docker-compose -f local.yml run --rm postgres list-backups
20
20
21
21
22
22
To restore a backup, run::
23
23
24
-
docker-compose -f local.yml run postgres restore filename.sql
24
+
docker-compose -f local.yml run --rm postgres restore filename.sql
25
25
26
26
Where <containerId> is the ID of the Postgres container. To get it, run::
You may notice that some elements of this project do not exactly match what we describe in chapter 3 of `Two Scoops of Django`_. The reason for that is this project, amongst other things, serves as a test bed for trying out new ideas and concepts. Sometimes they work, sometimes they don't, but the end result is that it won't necessarily match precisely what is described in the book I co-authored.
22
+
Why doesn't this follow the layout from Two Scoops of Django?
You may notice that some elements of this project do not exactly match what we describe in chapter 3 of `Two Scoops of Django 1.11`_. The reason for that is this project, amongst other things, serves as a test bed for trying out new ideas and concepts. Sometimes they work, sometimes they don't, but the end result is that it won't necessarily match precisely what is described in the book I co-authored.
26
26
27
-
.. _`Two Scoops of Django`: http://twoscoopspress.com/products/two-scoops-of-django-1-8
27
+
.. _Two Scoops of Django 1.11: https://www.twoscoopspress.com/collections/django/products/two-scoops-of-django-1-11
0 commit comments