Skip to main content

How to get two docker-compose services to talk to each other

Imagine you have two services that are started by two different docker-compose files. And you would like these two services to talk to each other. How can we achieve this?

Why would you want to do this in the first place?

I had a use-case for this, that's why! The use case was as follows:

I have a docker-compose file that contains linux-swag and mysql. These are resources that are not updated very often. So I can start them and forget about them.

I have another docker-compose file that contains a Spring Boot application. This application can have different versions (prod, staging, dev). And these version get automatically deployed on each git-push.

 


 

The nginx serves HTTPS and reverse-proxies connections to the spring application. The spring application connects to the mysql to read and store stuff.

The Secret Sauce

The way to do this is with docker-compose networking. You see by default each docker-compse file creates it's own bridge network. So by default, in my example, my nginx would be able to talk to mysql. But my spring application can't talk to mysql. For these services to be able to talk to each, they all have to be on the same network. And a good way to do this is to define your own bridge network. This can be easily done for the docker-compose 1 file as follows:

version: '3'
services:
  db:
    image: mysql:8.0.22
    restart: always
    environment:
      MYSQL_ROOT_PASSWORD: secret_root_password
      MYSQL_DATABASE: mydb
    volumes:
      - db_data:/var/lib/mysql
    networks:
      - my_bridge_network

  swag:
    image: linuxserver/swag
    container_name: swag
    cap_add:
      - NET_ADMIN
    environment:
      - PUID=1000
      - PGID=1000
      - TZ=Europe/Berlin
      - URL=example.com
      - SUBDOMAINS=www,dev
      - VALIDATION=http
    volumes:
      - /home/user/web-server/swag:/config
    ports:
      - 443:443
      - 80:80
    networks:
      - my_bridge_network
    restart: unless-stopped

networks:
  fmk_network:
    name: my_bridge_network
    driver: bridge

volumes:
  db_data: {}


Notice the networks block above. We are creating a bridge network here called my_bridge_network. And now nginx (which is in swag) to be able to talk to the spring application, the spring application needs to be in the same network.

version: '3'
services:

  spring-app:
    build: .
    ports:
      - "127.0.0.1:8080:8080" # for local testing
    volumes:
      - /home/user/spring-app/logs:/logs

networks:
  default:
    external:
      name: my_bridge_network

Notice the networks block above. Here we are asking docker-compose to not create a network (which is does by default). Instead, we are telling docker-compose to join a network called my_bridge_network.

Also note that the spring-app has it's Docker build file. So before bringing it up, you will need to run a build.


Of course there is stuff missing in my example. For example (😉) the nginx reverse proxy configs and the docker build file to build the spring-boot app. If you need that, let me know and I can create a working example on github.



Labels:

Comments

Post a Comment

Popular posts from this blog

Simpler alternative to Conventional Commits

TLDR: Just put the fucking Issue ID in the commit message, you asshat! I keep reading about Conventional Commits , and I think they are somewhat contrived and over complicate a simple requirement of commits: What context was a change made for. As we all know, information is somewhat useless without context. And I feel the same what about commit messages. And the best context in a commit message a link to the original Ticket in the Issue Tracking system. Most Issue Tracking systems support linking to the SCM , so that you can have a bi-directional link. If you look at an issue you can have a list of SCM changes done for that issue. For example, here is a JIRA issue showing what code change was done for it: And if I look into my SCM I can see the JIRA issues that were used to make changes: And the way to do this is to always have the Issue ID in the commit message. That's it. JIRA has this feature, so does Git Hub. That's all you need to do. Every commit message ...
2 comments
Read more

Postgres Timestamps and Java

Postgres timestamps are up to microseconds resolution. This can be seen here in the Postgres V13 docs . This means that if you are trying to save a ZonedDateTime type into to the DB, you should cut-off the Nano-seconds portion of the time. Otherwise, if you save a time with Nano secs, and you read that time back from the DB, you will have different times. This is because the time from the DB is missing the nano-secs. So how does one go about doing this? Rounding Nanoseconds Essentially do to this, first need to get the nano secs of the second via: Integer nanoSecs = zonedDateTime .get( ChronoField . NANO_OF_SECOND ) ; This amount now has to be converted to micro-secs by dividing by 1000. This removes the nano-seconds the amount. Don't forget that the nano-secs that we just removed by dividing may be more then 500. In which case you should add 1 to the microseconds. Then we need to multiply by 1000 to get the amount back in nano-secs. By doing this we turn all the nano-secs to ZERO...
Post a Comment
Read more