Tumblelog by Soup.io
Newer posts are loading.
You are at the newest post.
Click here to check if anything new just came in.

June 04 2018

Contributing to Django Framework is easier than you think

For those who are starting to code and wish to make open source, sometimes it is hard to start. The idea of contributing with that fancy and wonderful lib that you love can sound a little bit scary. Lucky for us many of those libs have room for whoever is willing to start. They also give us the support that we need. Pretty sweet, right? Do you know

Don't forget the stamps: testing email content in Django

When developing a web app how often do you check the emails you send are all working properly? Not as often as your web pages, right? That's ok, don't feel guilty, emails are hard to test and they are often someone's else responsibility to write and take care. This doesn't mean we should give up on them. There are some things we can do to prevent e

How I test my DRF serializers

How I test my DRF serializers In this blog post, I will show the whats and whys on testing Django REST Framework serializers. First, some context. Here is the model setup we are going to use for this example: from django.db import models class Bike(models.Model): COLOR_OPTIONS = (('yellow', 'Yellow'), ('red', 'Red&#

Django and React Boilerplate as an Asset in Software Development

Here at Vinta we believe that programmers, not processes, nor code, are the most important assets on software engineering. Due to that, we believe in using every tool available in order to facilitate our programmers' lives. One of our favorites is our boilerplate. If you are unfamiliar with the concept, a boilerplate is "any code block that is reus

Metaprogramming and Django - Using Decorators

While programming is about, in some way, doing code to transform data, metaprogramming can be seen as the task of doing code to change code. This category is often used to help programmers to enhance the readability and maintainability of the code, help with separation of concerns and respect one of the most important principles of software develop

Database concurrency in Django the right way

When developing applications which have real-time requirements or other specific needs for running asynchronous tasks outside the web application, it is common to adopt a task queue such as Celery. This allows, for example, for the server to handle a request, start an asynchronous task responsible of doing some heavyweight processing, and return an answer while the task is still running. Here, we are considering a similar scenario: a request is made, and the server has to do some processing on the request. Ideally, we want to separate the high time-demanding parts from the view processing flow, so we run those parts in a separate task. Now, let's suppose we have to do some database operations both in the view and the task when the request happens. If not done carefully, those operations can be a source for issues that can be hard to track.

Controlling access: a Django permission apps comparison

There are many ways to handle permissions in a project. This post highlights the main differences and approaches taken by some popular Django third party apps to handle permissions.

3 Django apps for sending great e-mails

3 Django apps for debugging and sending HTML styled e-mails

Uploading files from the frontend to Amazon S3

How to upload files from the frontend straight to S3 without sending to the server using django

10 Django apps you're not using but should be

Description of 10 essential apps every Django developer should be using in their projects

Classy Django REST Framework Release

Release of Classy Django REST Framework

A Basic SEO for Django

A Basic SEO for Django.

How to configure Sass and Bower with django-compressor - part 2 (deployment to Heroku and S3)

Quick guide on how to deploy Django with Sass, Bower and django-compressor to Heroku and S3

How to configure Sass and Bower with django-compressor - part 1 (local config)

Quick guide on how to configure Django with Sass, Bower and django-compressor

Django CORS

An introduction to CORS and how to enable it in Django.

June 03 2018

Reactify Django

# Reactify Django is coming. ...

June 01 2018

Django development with Docker — Testing, Continuous Integration and Docker Hub

May 31 2018

Ansible provision/deploy setup

I never got around to write down the ansible setup I figured out (together with others, of course, at my previous job) for deploying/provisioning django websites.

The whole setup (as a cookiecutter template) can be found in https://github.com/reinout/cookiecutter-djangosite-template . The relevant code is in the ansible/ directory. Note: this is a "cookiecutter template" from which you can generate a project so you'll see some {{ }} and {% %}: when you create the actual project these items will be filled in.

My goal was to keep the setup simple and safe. With "safe", I mean that you normally cannot accidentally do something wrong.

And it was intended for getting one website project onto the server(s). It is not a huge ansible setup to set up the whole infra in one fell swoop.

First the inventory files:

  • Yes, multiple: there are two of them. production_inventory and staging_inventory. The safe aspect is that we used to have a single inventory file with [production] and [staging] headings in it. If you wanted to update staging, you had to add --limit staging on the command line. If you forgot that...

    With two separate files, you never have this problem. Accidents are much less likely to occur.

  • The simple aspect is that variables are right there in the inventory. It are only a few variables after all: servername, hostname, checkout (master or tag).

    A "problem" with ansible is that you can place variables in lots of places (playbook, inventory, host variable file, group variable file and another two or three I don't remember right away). So where to look? I figured that the inventory was the right place for this kind of simple setup:

    [web]
    p-web-1234.internal.network
    
    [web:vars]
    site_name=myproject.example.org
    checkout_name="1.2"
    

Second, the ansible playbooks:

  • There are two. A provision.yml and a deploy.yml. Provisioning is for one-time setup (well, you probably want to change stuff sometimes, but you'll rarely run this one). Deploy is for the regular deploys of the actual code. The stuff you regularly do.

  • Provision should be run as a user that can do sudo su on the target machine. Provisioning installs packages and adds the nginx config file in /etc/. And it creates a user for running/deploying the django site (in my previous job, this user was historically called buildout).

  • The deploy playbook connects as the abovementioned deploy user, does a "git pull" (or whatever deploy mechanism you prefer), runs the database migration and so.

  • Now, how can the person who deploys connect as that deploy user? Well, the provision playbook creates the deploy user ("buildout"), disables the password and adds the public ssh keys of the deployers to the /home/buildout/.ssh/authorized_keys file:

    - name: Add user "buildout" and set an unusable password.
       user: name=buildout password='*' state=present shell="/bin/bash"
    
     - name: Add maintainers' ssh keys so they can log in as user buildout.
       authorized_key: user=buildout key=https://github.com/{{ item}}.keys
       with_items:
         - reinout
         - another_colleague
    

    It is simple because you only need a very limited number of people on any server with sudo rights. Or a very limited number of people with the password of a generic admin account. Re-provisioning is basically only needed if something changed in the nginx config file. In practice: hardly ever.

    It is simple because you don't need to give the deployers each a separate user account (or access to a password): their public ssh key is enough.

    It safe because it limits the (root-level) mistakes you can do during regular deploys. And the small amount of users you need on your system is also an advantage.

  • The ansible playbooks are short. Just a couple of tasks. Even though I'm normally all in favour of generic libraries and so: for a 65 line playbook I personally don't need the mental overhead of one or two generic ansible roles.

    The playbooks do basically the same thing I did years earlier with "Fabric" scripts. So: the basic structure has quite proven itself (for me).

There are all sorts of approaches you can take. Automatic deploys from your Jenkins or Gitlab, for instance. That'd be something I like to do once. For not-automatically-deployed projects, a simple setup such as I showed here has much to recommend itself.

GeoDjango and PostgreSQL

I recently had to set up GeoDjango on a site that used PostgreSQL as a database. As the online instructions for doing this were less than totally clear, I decided to write down how I did it.

May 30 2018

Django Local 404 Page

Learn how to display and customize a 404 page locally.
Older posts are this way If this message doesn't go away, click anywhere on the page to continue loading posts.
Could not load more posts
Maybe Soup is currently being updated? I'll try again automatically in a few seconds...
Just a second, loading more posts...
You've reached the end.

Don't be the product, buy the product!

Schweinderl