1045397 - Use separate docker containers for flask frontend and workers

Status: RESOLVED WONTFIX

(Release Engineering :: General, defect)

Description

[Anhad Jai Singh (:ffledgling)]

Currently Funsize is deployed/created as a single docker container, this isn't ideal for scaling the workers across multiple nodes on Amazon (EC2/EB).

We need to figure out how to split the current container into multiple containers that are easy to deploy, scale and work with in the local dev environment.

Comment 1

[Anhad Jai Singh (:ffledgling)]

The original idea behind this bug was to split the docker container into multiple containers, where each container handles a different "component" or piece of the application. (Frontend, Backend, Central services)
Upon some investigation, splitting the existing container into multiple containers, may not be the best idea. Linking docker containers with one another is a little problematic on your local developer machine (especially many to one linking) and I haven't found much in the way of linking multiple EB containers together either. Even if we do find a way to do what we're trying to do here, it will cause a large difference on how we work/develop on local machines and how things actually work in production.

A different possible solution that will allow us to scale and yet keep local dev and production deployment as close to possible is as follows.

Instead of having different types of docker containers for the following:
i) Flask
ii) Database, AMQP, Cache
iii) Celery workers

What we can do instead is have *one* container that has both flask and celery inside it.
Central services such as the DB, Cache and the Msg-Queue can be leveraged via other existing Amazon services such as RDS, S3 and SQS (or RabbitMQ on an EC2 instance if necessary).

When running on local machines, we can simply use the local file system and SQLite (or MySQL if we aim to be closer to production) within the same container.

We should ideally be make the application switch between "amazon mode" and "localhost mode" via a variable in the dockerfile.

Any obvious problems, flaws visible?
Is this a feasible way to go about implementing things for Funsize in the long run?

[Needinfo-ing lots of people to keep everyone in the loop, feel free to remove needinfo if you don't have input and/or your points are already covered by someone else]

Comment 2

[[e-mail] (:bhearsum)]

Given that you've requested info from others, and the fact that some unexpected high priority stuff came up yesterday, I'm going to remove myself here.

Comment 3

[Chris AtLee [:catlee]]

I think this is a reasonable approach to take in the short term. We can re-visit later if we need to.

Comment 4

[Nick Thomas [:nthomas] (UTC+12)]

Would be good to record the decision in today's meeting here.

Comment 5

[Anhad Jai Singh (:ffledgling)]

IRL meeting between all parties involved concluded that we would like to keep production and development as close to each other as possible, while meticulously documenting the differences.
We want to repo to work right out of the box and we should be able to switch between development and production versions via some form of configuration (Dockerfile, init scripts, env_variables)

Comment 6

[Rail Aliiev [:rail]]

(In reply to Anhad Jai Singh (:ffledgling) from comment #5)
> IRL meeting between all parties involved concluded that we would like to
> keep production and development as close to each other as possible, while
> meticulously documenting the differences.
> We want to repo to work right out of the box and we should be able to switch
> between development and production versions via some form of configuration
> (Dockerfile, init scripts, env_variables)

Sounds plausible to me