I was fighting the platform and I lost. Now I'm better for it
Tags: dohackathon, django, docker
Published: 2020-12-26 14:14:35

---
series: Building GoGreen on DigitalOcean App Platform Hackathon Series
cover_image: https://dev-to-uploads.s3.amazonaws.com/i/poajqew1bb0267vv5rge.png
 
---
 

Last modified 2020-12-26 22:20 SGT

It was after an email from the DO support followed by a Xmas eve dinner that I realized, I was fighting a losing war.

I started this hackathon insistent on using Django inside Docker because that's how basically I made my own living. You see, I write quotation sofware for a living and my main framework of choice is Django. The issue is that the client insists on deploying it on-premises.

I needed to reduce uncertainty. Uncertainty such as when the dev and production environment drifted too much. A key decision I made for all my Django apps is **always run Django inside Docker**. Regardless for development or production. It was a good decision because it reduced the number of moving parts.

I carried over that attitude into this hackathon and that was a mistake.

## The blindspot

I did notice from the various information sources that yes, DOAP has a standard way of deploying Django app directly within the App Platform without Docker. And the sources were plenty. From [sample code repositories](https://github.com/digitalocean/sample-django) to [tutorials](https://www.digitalocean.com/community/tutorials/how-to-deploy-django-to-app-platform), and even the [community questions](https://www.digitalocean.com/community/questions/app-platform-for-django-app).

Yet, I persisted with running Django inside Docker. I also came across a tutorial on running Docker container inside App Platform. So I was sure my way would have no issues.

Boy, was I wrong.

## There's no Nginx needed for DOAP

I have to give up my approach eventually. What turned it around was when I faced issues running `collectstatic` command inside the main App Platform component.

Don't get me wrong. The command works when I run it via the console inside the main component. 

But here lies the rub. The browser still cannot access the staticfiles regardless. 

The reason for this mysterious behavior is the way App Platform is setup. App Platform doesn't require your app to run its own Nginx or any other web server software because your app utilizes the DigitalOcean's global CDN. 

App Platform is a PaaS (Platform as a Service). Therefore, it tends to be more prescriptive on how the various components talk to one another. The idea is that DOAP prefers that you spin up a separate component to serve the static files. Hence, the CDN setup and the non-necessity of a Nginx.

Every architectural decision has its implications. With a decision like that, that means somehow the `collectstatic` command needs to run **inside the component** responsible for handling the `/static` route. Not inside the main component where the django is running in.

Since the console provided by DO has access to only the main component, therefore the developer is reliant on other ways to activate the `collectstatic` command. 

## Buildpacks contain automated commands

Recall I said earlier about how DOAP allows you to install Django directly into its app components? The way they do it is by using buildpacks (and they look like buildpacks from heroku). 

Inside the python buildpack meant to install Django, there is an automatic instruction to run the `collectstatic` command whenever there's a deploy. 

And I've noticed that if you choose to run the main component using Docker, the other related components such as the one for static files tend to inherit this setting. You cannot override it just at the static files serving component. You cannot choose to have the main component run using Docker and the other components run differently using standard buildpacks provided.

In other words, instead of this


![original plan](https://dev-to-uploads.s3.amazonaws.com/i/poajqew1bb0267vv5rge.png)


My setup is now

![current-plan](https://dev-to-uploads.s3.amazonaws.com/i/lcoahbc5l30vu1cofgal.png)
 
Well, at least I figured out in a deep sense (okay, deeper before I began) how the DigitalOcean's App Platform worked.

And I must say, DOAP is highly promising in terms of where they want to go with this. I can see how cool it eventually will become. 

Right now, if I were to choose which DO product to use for a small side project, I would still go with the Droplets.

## Time spent thus far 🕒

For first-time reader, this is the section where I explicitly share the time spent. This is to set realistic expectations for readers and myself. 

This week, I have spent much more time on this side project.

### So far

Total time so far: 27.8 hr
Dev work so far: 22.95 hr
Writing so far: 4.85 hr

Average per week: ~10 hrs of Dev work, ~2 hrs of Writing 

### Dec 10 to Dec 19 2020

In this period

Total time this period: 12.95 hr
Dev work this period: 9.1 hr
Writing this period: 3.85 hr

### Dec 20 to Dec 26 2020

In this period

Total time this period: 14.85 hr
Dev work this period: 13.85 hr
Writing this period: 1 hr

| Date                     | Work | Time |
| -------------------------- | ----- | ----- |
| 2020-12-21 | Dev    | 0.75 |
| 2020-12-22 | Dev    | 1.5 |
| 2020-12-23 | Dev    | 4.2 |
| 2020-12-24 | Dev    | 2.75|
| 2020-12-25 | Dev    | 4.65|
| 2020-12-26 | Writing    | 1 |

### 2020-12-26

1. Writing up this post 1 hr


### 2020-12-25

1. Upgrade everything: django, postgres, and python and test it locally 1.5 hrs
2. Abandon using docker to run django on DOAP 3.15 hrs

### 2020-12-24

1.Run `collectstatic` in main component does not work . Try all sorts of ways to fix it. 2.25hrs
2. Try to push the static files to repo to test theory 0.5 hrs

### 2020-12-23 

1. Adding custom domain, making allauth work with github on localhost 3.1 hrs
2. Make allauth work on remote 1.1 hrs


### 2020-12-22

1. the docker finally works locally 1.5hr

### 2020-12-21

1. work on making docker work locally 0.45hrs
2. then test run the docker running locally spend about 0.3  hrs