single container for PaaS deployment

[fdhex]

Hello,

To deploy in a more prd oriented setup, I'd like to try to deploy Cachet as a docker container on our PaaS, cloudfoundry-based. We have all sort of reliability issues when deploying with a buildpack in some environments, so I'd prefer the repeatability of a Docker container any day.

Would you suggest I try to work directly with the Cachet image here, or preferably straight from the code? I do not need (can't use) docker-compose, and anyway load balancing should be taken care of automatically by the PaaS.

Thanks!

[djdefi]

I am not familiar with cloudfoundry, but as long as it allows you to launch and link the DB and nginx containers it should work.

The manual run instructions should apply: https://docs.cachethq.io/docs/get-started-with-docker#running-containers-manually

I recommend using one of the tagged images from https://hub.docker.com/r/cachethq/docker/tags/ rather than latest, i.e. cachethq/docker:2.4.4

[fdhex]

Thanks for your answer. There cannot be any nginx container there, load balancing would be taken care of by the platform.

The DB can be linked (it will by a mysql though), can you think of any specific change you would do to the docker container in that case?

[djdefi]

Nginx in our case is acting as the webserver, not as a load balancer.

[fdhex]

Right, it is also not possible to have this in the current environment we're using, but it shouldn't be hard to deploy them in a single container right? I think it was actually deployed like that sometime ago.

[djdefi]

Would need to revisit / revert the nginx separation that was introduced in #46 - which I think is a valid move. I believe that any customizations to nginx could be done on the Cachet image itself without needing a separate nginx image, or by using a derived image (e.g. FROM cachethq/docker:2.2.4)

cc:
@zemirco (original pr submitter for the split)

[atmosx]

I have similar reqs with @fdhex, 👍 for adding nginx to cachet container.

[zemirco]

Keeping nginx out of this docker container makes the image smaller, simpler and easier to maintain.

If you really want a single cachet + nginx dockerfile why don't you just create one? That way we have both solutions. The small one without nginx and the bigger one with cachet and nginx inside a single container. That's the huge advantage of composition and small parts.

Anyway you have to make sure you are able to configure nginx inside your docker container and be able to pass a custom nginx.conf. You should also be able to pass SSL certificates, etc. That would blow up the cachet docker image if all this is added.

[fdhex]

I'll work on that when time allows, normally I also prefer composing services rather than having a bloated image, but sometimes it is not always possible.

I will not convince anyone where I am working to use isolated docker-compose managed software remotely near production, whereas a PaaS controlled docker container works for us, and in our context we can simply not link containers, it is not an available feature.

There is no need of any customization once the image is created afaik, the nginx.conf can just be put in the image and be configured to either read from env vars, or worst case I'll have an autostart script which fills it at runtime.

[atmosx]

Hello,

My situation is somewhat similar to @fdhex. Although in our infrastructure I can run linked containers, I don't appreciate the added complexity.

I have a working version by reverting the changes that were made in #46. I made some minor additions, like creating conf/php5 and using conf/files/. Here's the Dockerfile:

FROM debian:jessie

MAINTAINER Alt Three <[email protected]>

ARG cachet_ver
ENV cachet_ver master

# Using debian packages instead of compiling from scratch
RUN DEBIAN_FRONTEND=noninteractive \
    echo "APT::Install-Recommends \"0\";" >> /etc/apt/apt.conf.d/02recommends && \
    echo "APT::Install-Suggests \"0\";" >> /etc/apt/apt.conf.d/02recommends && \
    apt-get clean && \
    apt-get -q -y update && \
    apt-get -q -y install \
    ca-certificates=20141019+deb8u1 nginx php5-fpm=5.6.22+dfsg-0+deb8u1 php5-curl=5.6.22+dfsg-0+deb8u1 \
    php5-readline=5.6.22+dfsg-0+deb8u1 php5-mcrypt=5.6.22+dfsg-0+deb8u1 sudo=1.8.10p3-1+deb8u3 \
    php5-mysql=5.6.22+dfsg-0+deb8u1 php5-apcu=4.0.7-1 php5-cli=5.6.22+dfsg-0+deb8u1 \
    php5-gd=5.6.22+dfsg-0+deb8u1 php5-mysql=5.6.22+dfsg-0+deb8u1 php5-pgsql=5.6.22+dfsg-0+deb8u1 \
    php5-sqlite=5.6.22+dfsg-0+deb8u1 wget=1.16-1 sqlite=2.8.17-12 git=1:2.1.4-2.1+deb8u2 \
    libsqlite3-dev=3.8.7.1-1+deb8u1 postgresql-client=9.4+165+deb8u1 mysql-client=5.5.49-0+deb8u1 \
    supervisor=3.0r1-1 cron=3.0pl1-127+deb8u1 && \
    apt-get clean && apt-get autoremove -q && \
    rm -rf /var/lib/apt/lists/* /usr/share/doc /usr/share/man /tmp/*

COPY conf/files/php-fpm-pool.conf /etc/php5/fpm/pool.d/www.conf
COPY conf/files/supervisord.conf /etc/supervisor/supervisord.conf

RUN sed -i -e "s/;daemonize\s*=\s*yes/daemonize = no/g" /etc/php5/fpm/php-fpm.conf && \
    echo "daemon off;" >> /etc/nginx/nginx.conf && \
    rm -f /etc/nginx/sites-enabled/* && \
    rm -f /etc/nginx/conf.d/* && \
    rm -rf /etc/php5



COPY conf/files/nginx-site.conf /etc/nginx/conf.d/default.conf
COPY conf/php5 /etc/php5

RUN mkdir -p /var/www/html && \
    chown -R www-data /var/www

COPY conf/files/crontab /etc/cron.d/artisan-schedule
COPY entrypoint.sh /sbin/entrypoint.sh

RUN chmod 0644 /etc/cron.d/artisan-schedule && \
        touch /var/log/cron.log

RUN adduser www-data sudo && \
    echo '%sudo ALL=(ALL) NOPASSWD:ALL' >> /etc/sudoers

WORKDIR /var/www/html/
USER www-data

# Install composer
RUN php -r "copy('https://getcomposer.org/installer', 'composer-setup.php');" && \
    php -r "if (hash_file('SHA384', 'composer-setup.php') === 'e115a8dc7871f15d853148a7fbac7da27d6c0030b848d9b3dc09e2a0388afed865e6a3d6b3c0fad45c48e2b5fc1196ae') { echo 'Installer verified'; } else { echo 'Installer corrupt'; unlink('composer-setup.php'); } echo PHP_EOL;" && \
    php composer-setup.php --version=1.1.2 && \
    php -r "unlink('composer-setup.php');"

RUN wget https://github.com/cachethq/Cachet/archive/${cachet_ver}.tar.gz && \
    tar xzvf ${cachet_ver}.tar.gz --strip-components=1 && \
    chown -R www-data /var/www/html && \
    rm -r ${cachet_ver}.tar.gz && \
    php composer.phar install --no-dev -o && \
    rm -rf bootstrap/cache/*

COPY conf/.env.docker /var/www/html/.env

ENTRYPOINT ["/sbin/entrypoint.sh"]
CMD ["start"]

$ ls -l conf
total 0
drwxr-xr-x  6 atma  staff  204 29 Ιον 16:08 files
drwxr-xr-x  5 atma  staff  170 29 Ιον 13:34 php5

$ ls -l conf/files
total 32
-rw-r--r--  1 atma  staff   169 29 Ιον 09:53 crontab
-rw-r--r--  1 atma  staff   841 29 Ιον 13:37 nginx-site.conf
-rw-r--r--  1 atma  staff   404 29 Ιον 16:08 php-fpm-pool.conf
-rw-r--r--  1 atma  staff  1033 29 Ιον 16:02 supervisord.conf

$ docker build -t nginx-cachet:latest -f dockerfile

$ docker run --name mysql -e MYSQL_ROOT_PASSWORD=123 -e MYSQL_USER=user -e MYSQL_PASSWORD=pass -e MYSQL_DATABASE=cachet -v /var/lib/mysql -d mysql:5.6

$ docker run -d --name cachet -p 80:80 --link mysql:mysql -e DB_DRIVER=mysql -e DB_HOST=mysql -e DB_DATABASE=cachet -e DB_USERNAME=user -e DB_PASSWORD=pass -d nginx-cachet:latest

$ curl `echo $DOCKER_HOST|grep -E -o "(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\.(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\.(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\.(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)"`
<!DOCTYPE html>
<html>
    <head>
        <meta charset="UTF-8" />
        <meta http-equiv="refresh" content="1;url=http://192.168.99.100/setup" />

        <title>Redirecting to http://192.168.99.100/setup</title>
    </head>
    <body>
        Redirecting to <a href="http://192.168.99.100/setup">http://192.168.99.100/setup</a>.
    </body>
</html>%

[djdefi]

I am glad that this sparked a discussion. 👍

I can see both sides of the argument here. As a maintainer, I targeted the deployment and operational use cases that I have experience with, docker-compose and a standard Docker host in this case.

It is tough to be 100% compatible with every single Docker provider or infrastructure out there, especially ones that do not support the "bleeding edge" Docker feature set such as linked containers in the case of cloudfoundry.

I prefer to focus on new things like Docker stacks and Distributed Application Bundles (DABs) that can take advantage of the evolving Docker ecosystem and methodologies, rather than go back and change things to work around limitations of particular systems.

That being said, it sounds like there are two images that are wanted by the community:

• A super minimal image, breaking out everything into separate compose-able units. PHP-fpm probably should be it's own separate image also in this case.
• A Monolithic image, with php + nginx running via supervisor in a single container, which helps simplify the operational side somewhat (one less container to run and link).

There are some problems with either approach, and I welcome any suggestions (or PR's) for ways to make both sides happy. We are sort of inbetween both of those solutions at this point, and I am open to offering both options as long as the overhead of maintaining both ways is not a huge burden. We welcome any volunteers that would like to help tackle these things.

[djdefi]

So I have been thinking about this, and I am leaning towards 3.4 release moving to a Alpine Linux based image, and including nginx in the Cachet image once again. A bit more monolithic, but the extra container for just nginx adds some complexity and issues. (#106)

If a custom nginx or config is needed, just mount one in via a volume, or derive your own image i.e. FROM cachethq/docker:3.4

This repo and image is really meant to be an example, and I would expect / hope that people using Cachet in Docker for critical production systems are doing their own builds in CI or their own docker hub accounts. If I was running Cahet in Docker in my own infrastructure, I would want to do some customization to the docker-compose.yml, use another orchestration tool, build the container on my own build system, and maybe even add some additional customizations that are specific to my environment.

TL;DR: This is an "official" example of how to run Cachet in Docker. Administrators need to make their own decisions and modifications to fit their infrastructure needs, just as you would with a traditional server. Docker is not a "one size fits all" solution.

[gamkiller77]

I just went though the pain of covering the docker-compose in to a valid OpenShift 3.2 deployment and having the nginx and cachet all in one docker image would make it work. I have yet to see a way to share a volume in kubernetes from one pod to another pod. So having a singular image with cachet and nginx all rapped up.

[gamkiller77]

I have been able to rap all the items in to a single container image now. I am going to test this now on my Openshift 3.2 setup to see if it all works.

I have gotten it work for just fine with OpenShift 3.2 / Kubernetes 1.2.

Also for those wondering what the change with adding the nginx packages to the cachet contianer image the change was small a gain of 2Megs.

[gamkiller77]

I can commit my code to this project if you all want it working fine for me.

[sheaphillips]

@gamkiller77 care to share / point to your OpenShift config for Cachet?

[gamkiller77]

@sheaphillips I will do a PR this week with the base yaml files and some instructions. I just redeployed my setup on OpenShift 3.3

[gamkiller77]

@sheaphillips PR submitted

[sheaphillips]

Thanks!

…

Sent from my iPhone

On Jan 29, 2017, at 11:23 PM, Andy del Hierro ***@***.***> wrote: @sheaphillips PR submitted — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.