- Common Loki Misconfigurations
- Iterating Through a List in Ink
- Debugging Misconfigured Container Networks
- Minimum Viable EC2 in Terraform
- Storylets in Ink
- Interactive Fiction Tooling Overview
- In-Place Resizing for Digitalocean Droplets
- Unity Demonstrates the Importance of FOSS
- Target Labels in Prometheus
- My View of AI is the Same
- Verify DNS Ownership with TXT Records
- Sane Droplet Defaults
- Editing Made Easy with Vim
- Gatsby Gotchas
- Concatinating Default AWS Tags in Terraform
- Easily Updating the Default Github Branch
- Lifetimes in Rust
- Checking for Bad Links
- Maybe TypeScript and React is Bad
- Static Asset Management in React
- Bundler Down Time
- Using React Context for Localization
- JS Implementation of a Sticky Footer
- Custom Aliases
- Trying Out the 7drl Challenge
- Trash Opinions
- Building Your First Program in Rust
- Fixing mongod reports errors related to opening a socket
- Improving Open Source Maintenance
- Technical Interviewing Tips
- Housekeeping Note
- Dynamic Programming Basics
- The Oddity of Naming Conventions in Programming Languages
- An Experiment Using Machine Learning, Part 3
- Debugging with grep
- An Experiment Using Machine Learning, Part 2
- An Experiment Using Machine Learning, Part 1
- The Value of while
- National Day of Civic Hacking
- OpenAI and the Future of Humanity
- Creating a Whiteboard App in Django
- Creating Meaningful, Organized Information
- Towards A Critique of Social Media Feeds
- Setting up Routes in Django
- Developing a Messaging Component for Code for SF
- Dream Stream 2.0
- Keyed Collections in Javascript: Maps and Sets
- Blog Soft Relaunch
- Scraping with Puppeteer
- Looking Ahead to Dream Stream 2.0
- Solving West of Loathing's Soupstock Lode Puzzle
- Installing Ubuntu
- Interview with David Jickling Evaluation
- Compare Text Evaluation
- Dream Stream Evaluation
Debugging Misconfigured Container Networks
A common issue when debugging your container environment is you have a container application deployed to a particular port, say 3000
, and then you have another container running a reverse-proxy service so that it redirects HTTP traffic to HTTPS, and then serves up the content of your application running on port 3000. But when you check on your browser you encounter a 503 error.
The error you could be running into at this point is that you have your container network misconfigured. That can be discovered with the following command:
docker ps --format "\t"
Note I am using docker here as the most familiar example, but it should work the same way if you use other container services like containerd or podman.
This will provide a list of the name of your deployed containers and what network they belong to.
If your deployed containers are on different networks, then they are isolated from one another. You can change that with the following command:
docker network connect <network name> <container name>
If you want to create a new network instead of an existing one you would do docker network create <network name>
first.
Another issue that can happen during deployment is your container running the reverse proxy is unable to lookup the internal IP address of your application (possibly because they are running on different container networks!)
You can find a container’s internal IP address with: docker inspect --format '' <container name>
In general, it’s always good if you can apply some filters to a docker inspect
query because by default you get a lengthy JSON file returned that can take awhile to find the relevant information you’re looking for.
Now you should have an internal IP address for your application, something like, 172.17.0.2
. Now you can run docker exec -it <reverse proxy container> /bin/bash
and the proceed to edit the container’s config file. If you were using nginx-proxy you would look for the upstream block for your domain, and replace the server
line with:
upstream <url> {
server 172.17.0.2:3000;
}
Or a Caddyfile:
<url>
reverse_proxy :3000
After restarting the container you should be receiving content again.