Docker Compose and Zabbix

Description

Intro

I’m having trouble wrapping my head around Docker’s concepts and how they would fit a particular use-case: Zabbix. I’m hoping you folks can help me rethink my methodology and come up with a more “Dockerized” solution.

What is Zabbix?

For those of you unfamiliar, Zabbix is an open-source enterprise monitoring software much like Cacti, Nagios, etc. The software is comprised of the following components:

  1. Zabbix Server (Receives data and stores in database)
  2. Database (MySQL/PostgreSQL/etc)
  3. PHP Frontend (admin/user interface)
  4. Agents (collects data)

Goal

Given the components listed above, and sticking to the credence of “one process per container,” it makes sense to me to create a container per component and use Docker Compose to handle all of the server-side applications (Server, Database, Frontend). Hopefully that’s correct.

Actions

Current Status

My Project @ GitHub holds a development branch where I’m trying to incorporate Docker Compose. Here is my docker-compose.yml file contents:

source:
    image: br1husk/centos7-zabbix-source
    volumes:
      - /source
db:
    image: mysql/mysql-server
srv:
    build: ./server/
    volumes_from:
      - source
    links:
      - db:database
web:
    build: ./frontend/
    volumes_from:
      - source
    links:
      - db:database
    ports:
      - "8080:80"

My general thought process was thus:

  1. Compile Zabbix from source in CentOS7 container and store in a volume to later be accessed by other containers.
  2. Run make on server container with configured application on source
  3. Run COPY on frontend container with configured PHP files from source
  4. Link db service with frontend and srv, so they can communicate with the database without opening the ports to the network.

Problems

  • Compiling the source code in source and then accessing that as purely a volume container doesn’t seem to be the right way to go. Subsequent containers need to build before being able to mount the contents of /source, but I need to access those contents during the build.

Questions

  • For applications which rely on multiple components (such as a database/server/web interface), what’s a good way going about first compiling that and then splitting the components into containers?
  • Should I consider EXTENDing the srv/frontend containers from source instead of trying to compile everything in a single volume container? That would give me access to the configured software, but I’m not sure how to remove the unnecessary files after getting what I need. I wish to avoid bloating my containers by having them all contain a full copy of the compiled software. (Frontend doesn’t need server software. Server doesn’t need PHP libs.)

Thanks for the help!