If you have ever worked with Nginx, you know that one of its main use cases is to place it at the front of your application and use it as a reverse proxy to enhance security, performance, and scalability — among other benefits. In this guide, we will configure a Docker architecture where a Go application communicates with the outside world through an Nginx server, with each component running in its own container.

I’m assuming you know how to use Docker and you are also familiar with Docker Compose. Otherwise, this guide might be a bit challenging to follow, so I recommend reviewing the basics of Docker and Docker Compose before proceeding.

Project Organization

Let’s start with the project organization. For this example, I have a simple REST API written in Go with only one endpoint. I’ve simplified it since this guide focuses more on the Docker setup rather than on building APIs in Go.

nginx-go/
├── compose.yml
├── go-app/
│   ├── cmd/
│   │   └── main.go
│   └── Dockerfile
└── nginx/
    ├── Dockerfile
    └── nginx.conf

Go App Configuration

We’ll take a look at the go-app/cmd/main.go first

package main

import (
   "fmt"
   "log"
   "net/http"
)

func indexHandler(w http.ResponseWriter, r *http.Request) {
   fmt.Fprint(w, "Nginx server as a reverse proxy!")
}

func main() {
   http.HandleFunc("/", indexHandler)
   log.Fatal(http.ListenAndServe(":3000", nil))
}

Basically, it contains the configuration for starting the app and handling incoming requests properly. As mentioned, it’s a simplified version, with all the code located in the main.go file, which we would typically avoid in more complex scenarios. However, since the focus here is on Docker, we won’t go deep into the Go code.

Taking a look at the go-app/Dockerfile

FROM golang:1.21.3 AS builder

WORKDIR /app

COPY /cmd/main.go ./cmd/

RUN go mod init go-app

RUN CGO_ENABLED=0 GOOS=linux go build -o /go-app ./cmd/main.go

FROM scratch

WORKDIR /

COPY --from=builder /go-app .

EXPOSE 3000

CMD [ "/go-app" ]

The purpose of this Dockerfile is to build the Go binary to run on a lightweight image. It’s as simple as that.

Note that port 3000 in the Go container is exposed within the network, but we won’t expose it to the outside.

Nginx configuration

Here’s where things start to get more interesting. To place Nginx in front of the Go application, we need to configure the Dockerfile for Nginx (as usual) and also configure the nginx.conf file to reroute the requests received by the Nginx server to the Go application running on port 3000. Let’s look at the Dockerfile for Nginx.

nginx/Dockerfile

FROM nginx:latest

EXPOSE 80

ENTRYPOINT ["/docker-entrypoint.sh"]
CMD ["nginx", "-g", "daemon off;"]

It typically builds the image and starts the server exposing port 80.

nginx/nginx.conf

server {
    listen 80;

    server_name localhost;

    location / {
            proxy_pass http://go-app:3000;
            proxy_http_version 1.1;
            proxy_set_header Upgrade $http_upgrade;
            proxy_set_header Connection 'upgrade';
            proxy_set_header Host $host;
            proxy_cache_bypass $http_upgrade;
        }
}

The nginx.conf file is the trickiest part, as it specifies where to send the requests received on port 80. Here, we set proxy_pass to route the requests to http://go-app:3000. Since Docker containers know the names of other containers (due to built-in DNS resolution), they can communicate with each other using just the name and port (http://go-app:3000).

Docker Compose Configuration

We’re using Docker Compose to automate the process of setting up and running the containers. In this compose.yml file, we are configuring the Go app and the Nginx server to run on the same go-network, which is also defined in the compose file. In the configuration for the Nginx container, we're mapping port 8080 from our system to port 80 of the Nginx container, so we can easily access it from localhost:8080.

We also create a volume to map the nginx/ folder in our working directory to the /etc/nginx/conf.d/ folder inside the container, so our nginx.conf file can be placed inside the Nginx container.

compose.yml

version: '3'

services: 

  app:
    build: 
      context: go-app
    container_name: go-app
    networks: 
      - go-network

  nginx:
    build: 
      context: nginx
    container_name: nginx
    volumes: 
      - ./nginx:/etc/nginx/conf.d/
    networks: 
      - go-network
    ports: 
      - "8080:80"
    depends_on:
      - app

networks: 
  go-network:
    driver: bridge

Running Everything

With all that done, we can now run these containers in detached mode and check if everything went well. We will open the terminal and run the following command:

docker compose up -d

No errors occurred, so this looks promising. Now, we can open the browser and try to access localhost:8080 to see the result.

Great! We can see the response from the index endpoint that we configured. Since the Go app is running on port 3000, we know that Nginx is correctly redirecting from its own port 80, which we bound to our 8080. This means everything is working as expected.

Conclusion

I hope this guide has given you insight into how you can easily configure your Docker environment to use Nginx as a reverse proxy for a Go app. I’ve chosen to use Go as an example, but the configuration structure is almost the same for any app written in any language. So, if you want, this setup can be adapted without much hassle.

You can check the source code for this guide on Github.

Configuring Nginx as a Reverse Proxy for a Go App in Docker. was originally published in Geek Culture on Medium, where people are continuing the conversation by highlighting and responding to this story.

This is the moment where some developers feels lost: the deployment time. Something that should be trivial, sometimes isn’t, but it shouldn’t be so hard at all — in fact, it is not. Hopefully, by the end of this guide, you’ll be able to host your Django project on Heroku, which is a great cloud service, especially because Heroku is a cloud PaaS (Platform as a Service) and also offers a free plan with which you can deploy your project with a full database provision.

Before you start, you have to make some configurations on your project to make it work on the server. There’s a difference between development and production and this tutorial will guide you thru it.

Note: I’m assuming you’re using a virtual environment. You also have to create a requirements.txt file and add all the python packages required to run your web application (including Django itself) to it. If you haven’t created this file, you can do this running the following command on your terminal:

pip3 freeze > requirements.txt

First of all, you need a Procfile , which is used to declare the application process type. This file must be located in your project’s root directory. You can create one running the following command on your terminal:

echo "web: gunicorn PROJECT_NAME.wsgi" > Procfile

Where PROJECT_NAME is the name of your Django project.

Next, you need to install some packages to make the application work on the server. These are the required packages:

• gunicorn (an application server)
• dj-database-url (for the database)
• whitenoise (for serving static files)
• psycopg2 (for postgres database)

To install them all in once, just go to your terminal and run:

pip3 install gunicorn dj-database-url whitenoise psycopg2-binary

After the installation has completed, add them to your requirements.txt:

pip3 freeze > requirements.txt

Now you have to create a runtime.txt file in your root directory — just like the Procfile — and add the python version you’re using. To check which python version you're using, run:

python3 --version

The output will be something like this:

Python 3.8.5

Since I’m using Python 3.8.5, to create the runtime file and add the python version, I can just run the following command:

echo "python-3.8.5" > runtime.txt

You should also create a .gitignore file and add the sqlite database to it as long as the virtual environment folder. To do this run:

echo "db.sqlite3" > .gitignore
echo "env/" >> .gitignore

where env/ is the name of your virtual environment.

Note: The second command should use two arrows ( >>) instead of just one ( >), because you’re appending to the file. Using one single arrow ( >) would replace the content of the file with the new one.

Now you have to configure some of the project files to make the application work on the server. First, go to the settings.py file and do the following:

• To allow whitenoise to handle the static files, you have to add the following line to the list of INSTALLED_APPS:

• Add the following line to ALLOWED_HOSTS list:

• You also have to set Debug to False:

• Now you have to add whitenoise to the MIDDLEWARE list, but this part is tricky — the whitenoise middleware should be included right after the django.middleware.security.SecurityMiddleware

• Now you have to add the configuration for the static files. At the bottom of your settings.py , add these lines:

Finally, but not least, you have to configure the Postgres database

• Right after the DATABASES dictionary, add the following lines:

Yeah, that was a lot, but now your app is ready.

Heroku Part

Now you have to set up your Heroku account (if you don’t have one). It can be done here.

You also have to install the Heroku-CLI. If you are on Mac, you can install running:

brew install heroku/brew/heroku

If you are on Linux (Ubuntu), run:

sudo snap install heroku --classic

On Windows, you have to download the installer, which can be done from this page.

After the installation has finished, you have to log in. On your terminal, run:

heroku login

…and follow the instructions.

Now, to create a new app, run:

heroku create PROJECT_NAME

where PROJECT_NAME is the name of your project.

Next, commit your changes and push your project to deploy your app:

git add -A
git commit -am "commit message"
git push heroku master

And that’s it, congrats! You just deployed your app. But you still have to configure the database. To add the Postgres add-on, you have to run:

heroku addons:create heroku-postgresql:hobby-dev --app PROJECT_NAME

where PROJECT_NAME is the name of your project.

Now you migrate to the database:

heroku run python manage.py migrate

Finally, you have to create a superuser:

heroku run python manage.py createsuperuser

If everything went well, you’ve successfully deployed your Django app. To open your app, run:

heroku open

All done!

If you got this far, congratulations! You not only deployed your project to Heroku but also learned a lot of new stuff — I hope so.

Thanks for reading!

How to Deploy a Django App on Heroku was originally published in Geek Culture on Medium, where people are continuing the conversation by highlighting and responding to this story.

Everyone who uses Django knows how good the Django forms can be. But when you are using it for the first time, a question araises: How can I style it? How can I add a class?

Well, there’s a way (quite simple actually), you have to use widgets.

But what is that exactly? Let’s see the definition of widget, according to Django Docs:

A widget is Django’s representation of an HTML input element. The widget handles the rendering of the HTML, and the extraction of data from a GET/POST dictionary that corresponds to the widget.

In other words, widget is just a way to define how that content will be rendered as HTML. So, for example, a CharField has a default widget of TextInput that renders as <input type="text"> .

But widgets are customizable, so you can also set things like the size of that textarea or if that field is going to be a required field and so goes on…

So, let’s try to build a example to show the widgets in action.

Suppose we have a form called UserInfoForm to get the name of the user and also his email.

And the HTML looks like this:

Right now this form is using the default widgets, and it doesn’t have any style, so, basically, it looks like this:

So, to change it, we need to customize the appearance. You can customize widgets in two ways — it can be via widget instance or widget class. For this first example, I’ll be using widget instance. Basically you have to use the Widget.attrs argument, which is a dictionary containing HTML attributes to be set to the rendered widget, like the example below:

And then we can see the attrs dictionary taking placeholder as a key an the Name as value as long with the style as key and the width: 300px; as value.

And this is the result:

Much better, right? But it still can be improved, we can add a Bootstrap class to it. And we can do this by declaring a class inside the attrs dictionary.

We’ve added a Bootstrap class and this is the result.

Now it’s good!

But usually when we are using Django forms, those forms are related to some model — and right now, this form isn’t. To that happen, we need to make a few more changes. We’re going to use the widget class now. The widget class has a basic attribute attrs, just like the the example above. We also have to add a new class called Meta and specify the name of the model this form is related to, the fields we want to have and finally the widgets for those fields.

So, what’s going on here? The CharField and the EmailField that we were using before are Built-in Field classes, but if we are going to work with widgets class, we need to use the Built-in widgets (and these widgets are TextInput and EmailInput, for this example). They will work the same in the end but the configuration will be slightly different.

This is basically the same form as before, it didn’t change the way it gets rendered or anything, but now this form is connected to the User model, which is the one that was created to store the user info.

And the HTML looks like this:

The final result:

Conclusion

Learning how to use widgets is great because now you know how to make those forms look better and how simple it is to add a Bootstrap class, which can be handy.

You can check the source code of this project on Github.

Of course there’s much more you can do with widgets. And the best place to learn is from the official documentation — aka Django docs.

How to Style Your Django Forms was originally published in The Startup on Medium, where people are continuing the conversation by highlighting and responding to this story.