Hey there! Let's work through getting your Go web app properly connected to RabbitMQ and MongoDB in Docker. I'll break down the fixes for the connection issue, how to use environment variables effectively, and best practices for initializing those external service connections.

Why localhost Fails in Docker #

Each container in your Docker Compose setup runs in its own network namespace. When your web app container uses localhost, it's referring to its own container—not the RabbitMQ or MongoDB containers. Instead, Docker Compose automatically creates a shared network for your services, and you can reach other containers using their service names (like rabbitmq and mongodb) as hostnames.

Switching to Environment Variables (The Right Way) #

Ditching the config.toml for environment variables is a great call—it makes your app more flexible for different environments (local dev, staging, production). Here's how to set this up:

1. Update Your Go Code to Read Environment Variables

Add a helper function to safely read env vars with fallbacks (so you can still run the app locally without Docker). Here's an example:

package main

import (
	"os"
)

type Config struct {
	MongoServer string
	Database    string
	RabbitMQURL string
}

// getEnv reads an environment variable, or returns a fallback if it's not set
func getEnv(key, fallback string) string {
	if value, ok := os.LookupEnv(key); ok {
		return value
	}
	return fallback
}

func LoadConfig() *Config {
	return &Config{
		MongoServer: getEnv("MONGO_SERVER", "localhost"),
		Database:    getEnv("DATABASE", "collect_db"),
		RabbitMQURL: getEnv("RABBITMQ_URL", "amqp://guest:guest@localhost:5672/"),
	}
}

Now your app will use the env vars if they're set (like in Docker), and fall back to localhost for local development.

2. Configure Environment Variables in docker-compose.yml

Update your web service to pass the correct hostnames via env vars. You can also remove the links field—it's a legacy feature, and Docker Compose's default network already lets services communicate using their names:

version: '3.9' # Use a newer version to support healthcheck conditions later
services:
  rabbitmq:
    image: rabbitmq
    ports:
      - 5672:5672
  mongodb:
    image: mongo
    ports:
      - 27017:27017
  web:
    build: .
    image: palash2504/collect
    container_name: collect_service
    ports:
      - 3000:3000
    depends_on:
      - rabbitmq
      - mongodb
    environment:
      - MONGO_SERVER=mongodb
      - DATABASE=collect_db
      - RABBITMQ_URL=amqp://guest:guest@rabbitmq:5672/

Best Practices for Initializing External Connections #

Even with the right hostnames, your app might try to connect before RabbitMQ or MongoDB are fully ready. Here's how to fix that:

1. Add Connection Retries in Your Go Code

Implement retry logic for both MongoDB and RabbitMQ connections to handle startup delays. Here's an example for MongoDB:

import (
	"context"
	"fmt"
	"time"
	"go.mongodb.org/mongo-driver/mongo"
	"go.mongodb.org/mongo-driver/mongo/options"
)

func ConnectMongoDB(cfg *Config) (*mongo.Client, error) {
	ctx, cancel := context.WithTimeout(context.Background(), 30*time.Second)
	defer cancel()

	var client *mongo.Client
	var err error

	// Retry up to 5 times with 2-second gaps
	for attempt := 0; attempt < 5; attempt++ {
		client, err = mongo.Connect(ctx, options.Client().ApplyURI("mongodb://"+cfg.MongoServer+":27017"))
		if err == nil {
			// Verify the connection works
			if pingErr := client.Ping(ctx, nil); pingErr == nil {
				return client, nil
			}
		}
		time.Sleep(2 * time.Second)
	}

	return nil, fmt.Errorf("failed to connect to MongoDB after 5 retries: %w", err)
}

And a similar retry loop for RabbitMQ:

import (
	"fmt"
	"time"
	"github.com/streadway/amqp"
)

func ConnectRabbitMQ(cfg *Config) (*amqp.Connection, error) {
	var conn *amqp.Connection
	var err error

	for attempt := 0; attempt < 5; attempt++ {
		conn, err = amqp.Dial(cfg.RabbitMQURL)
		if err == nil {
			return conn, nil
		}
		time.Sleep(2 * time.Second)
	}

	return nil, fmt.Errorf("failed to connect to RabbitMQ after 5 retries: %w", err)
}

2. Use Docker Health Checks (Optional but Recommended)

To make sure your web app only starts after RabbitMQ and MongoDB are ready, add health checks to those services and update depends_on to wait for them to be healthy. Update your docker-compose.yml:

rabbitmq:
  image: rabbitmq
  ports:
    - 5672:5672
  healthcheck:
    test: ["CMD", "rabbitmq-diagnostics", "-q", "ping"]
    interval: 5s
    timeout: 5s
    retries: 5

mongodb:
  image: mongo
  ports:
    - 27017:27017
  healthcheck:
    test: ["CMD", "mongosh", "--eval", "db.adminCommand('ping')"]
    interval: 5s
    timeout: 5s
    retries: 5

web:
  # ... other config ...
  depends_on:
    rabbitmq:
      condition: service_healthy
    mongodb:
      condition: service_healthy

This ensures your web service won't start until both RabbitMQ and MongoDB are ready to accept connections.

Quick Bonus Tip #

For cleaner configuration, you can store your environment variables in a .env file (Docker Compose automatically loads this):

# .env file
MONGO_SERVER=mongodb
DATABASE=collect_db
RABBITMQ_URL=amqp://guest:guest@rabbitmq:5672/

Then you can remove the environment section from your web service in docker-compose.yml—it will pick up the vars from .env automatically.

内容的提问来源于stack exchange，提问作者Palash Nigam