I make a change on the local server (something obvious, removing a <h1/>). I see it on the local machine. I then commit and push the changes and do cap deploy.
I do not see the changes when I access my staging environment.
I checked the following: Capistrano does not give me an error. I ssh onto the server and in the code, the change IS there. I restart the server manually by sudo touch tmp/restart.txt, but still I cannot see the change in the browser. Symbolic links from current/ point to the correct revision folder.
What can be causing this? The only thing I'm doing non-standard I think is that I do not deploy in production, but rather in environment called dev2. So my server start command is sudo passenger start -e dev2 -p 80 --user=ubuntu (btw, how should I deploy passenger in production? passenger start always deploys it in development, for some reason).
So to summarize, when I deploy with capistrano, I don't see the changes, although the server is restarted and the codebase does have the changes.
Related
I'm running Docker 19 on Windows 10 for development. A container volume binds directly to a Git repo folder and serves the Django app in that folder. I use Mingw-w64 to run Git (aka Git Bash).
Occasionally, I'll do the following (or something similar to the following):
Request a page served by the Docker container. (To replicate an error, for example.)
Switch to a different branch.
Request a page served by the Docker container from the new branch.
Switch to a different branch.
On the last branch switch, Git will freeze for a bit and then say permission denied on a particular file. The file is a difference between the two branches, so Git is trying to change it.
Process Explorer tells me the files are used by the system process so the only way to get it to let go is by restarting.
My gut is telling me the Django web process (manage.py runserver) is likely locking the file until the request connection is fully closed and is probably lingering as an established connection.
Is my gut right? If it is... Why is the lock held by the system process and not Docker? Is there anything to do to check before I do a branch change? Is there any way to prevent it from happening at all?
I am trying to update files on a project that already has been deployed. The changes are not taking place when seeing it deployed, though when I sudo vim these files via GitBash, it shows the changes. Here's how I did when I'm logged into the server Ubuntu via AWS.
cd into the project
git add .
git commit -a -m "message"
git pull origin master
(it comes out a Nano screen--so I input a message then Ctrl X and then respond "no") and it shows the changes through vim.
There's no changes when I refresh the deployed project, and not even when I reboot it via AWS. Can someone please share the steps to make changes and show changes on a deployed project? Thank you so much, I appreciate your feedback!
You need to restart the service running your app to update the app:
sudo systemctl restart service_name
I'm following this Docker tutorial, which creates a simple Docker-managed Django site, and when I try to run docker-compose up to launch my docker project, I get the ambiguous error:
ERROR: Couldn't connect to Docker daemon at http+docker://localunixsocket - is it running?
The error suggests that the Docker daemon isn't running, but service docker status shows the Docker daemon is running.
If instead I run sudo docker-compose up, then it succeeds, but it chowns a lot of my local development files to the root user, which is easy enough to fix, but annoying.
Why does Docker require root access just to start a local Django development server? How do I fix this?
My versions:
Docker version 18.06.1-ce, build e68fc7a
docker-compose version 1.11.1, build 7c5d5e4
Ubuntu 16.04.5 LTS
If you can run any Docker command at all, you can trivially root the host:
docker run --rm -v /:/host busybox \
cat /host/etc/shadow
Additionally, Docker containers frequently run as root within their own container space, which means that whatever parts of the host filesystem you choose to expose into them, they can make arbitrary changes as arbitrary user IDs. You can use a docker run -u option to pick a different user ID, but you can pick any user ID, even one that belongs to another user on a shared system.
It is very reasonable to use sudo as a way to get root privileges for things that need it, and this is a typical out-of-the-box Docker configuration.
At the end of the day the only real gate on this is the Unix permissions on the file /var/run/docker.sock. This is often mode 0660 owned by a dedicated docker group. If you don’t mind your normal user being able to read and write arbitrary host files without much of a control at all, you can add yourself to that group. That’s frequently appropriate for something like a developer laptop; but on anything like a production system it deserves some real consideration of its security implications.
What is the best practice when I have an update for my Django app pushed in my production? Shall I restart both gunicorn and nginx services, with
sudo service gunicorn restart
sudo service nginx restart
or restarting only gunicorn is enough? Finally does the order of the restarts makes any difference if I have to do both the restarts? Thanks!
It entirely depends on how you've configured your box.
To keep downtime to an absolute minimum, I actually load my new release into a different directory on the box while the old release is still running. I create a new virtual environment based on my new release's requirements.txt. Then I start a second instance of gunicorn with the new release running in it (done via supervisord with entries in supervisord.conf), and leave the old instance still running.
I then update my nginx vhost file to point the server to the new release's gunicorn socket, and finally reload nginx. I do a quick check that the new site is up and functioning, and then I stop the old gunicorn instance. If for some reason it's not responding, I switch my nginx config back to point to the old one again, and then go figure out what's wrong.
I do all this using an Ansible script, but here's a great article with some Fabric scripts to do something similar: https://medium.com/#healthchecks/deploying-a-django-app-with-no-downtime-f4e02738ab06
If, on the other hand, you just update your code in-place, then there should be no changes needed to your nginx config, so you shouldn't need to reload it. Just reload gunicorn and you're good to go.
I've got several questions. I have no idea how the heck to deploy...
After doing "svn up" on my production server, I'm not sure how to "refresh" my server so that the changes are reflected when you visit it. What can I do to refresh my server to see the changes in production? (I tried rebooting.)
I also noticed that some of the files that I changed weren't truly updated. I deleted a file and saw that doing "svn up" would bring the file back. I went back and deleted everything in the web app's folders, including the svn files (probably a mistake). (I should be safe since I have the prod revisions on the test server, I assume...) So, how can I bring these files back?
I need all the advice and resources on this that I can get. Feel free to post anything else that will get me through this process.
It depends how you run your django up. If you're serving with mod_python/modwsgi, a simple apache restart does the trick.
If you're datamodel changed, you may need to call south command migrate.
On most Linux-Systems this can be done with service apache2 restart
You can do the svn up, manage.py migrate and service apache2 restart with fabric
Fabric helps you to automate to execute shell commands over ssh.
If you are deploying on mod_wsgi you can simply touch the .wsgi file and it will reload the app without having to restart your whole server/httpd/etc