Deploy development branch and master branch to Google Cloud with Kubernetes

[mariobehling]

Most developers have already deployed loklak to Google cloud. How can we now automate this process and automatically deploy loklak to the cloud.

There should be two deployments:

1. Deployment from development branch for testing.
2. Deployment from master branch for production.

Before we switch the loklak domain to the cloud deployment, please implement the flow and test it for several days.

[mariobehling]

@sarishinohara @djmgit @kavithaenair @vibhcool @Achint08 @hemantjadon @singhpratyush @SKrPl This has a high priority for all of us.

[Orbiter]

Kubernetes is a good thing but it's there to scale stateless microservices. loklak has two storage locations which makes it a stateful microservice: the embedded elasticsearch and data dumps. In case that we use loklak services only for scraping we can just ignore that statefull behaviour but must then take care of the storage space that is used. We can also turn loklak into a full stateless microservice by:

• using an external elasticsearch (thats possible right now), and
• switching off the dump generation (that must be implemented with a flag).

for both we need a deployment with special settings. To go for full stateless microserivce operation we must implement the second point.

[singhpratyush]

@Orbiter @mariobehling @niranjan94 @kavithaenair

using an external elasticsearch

External Elasticsearch would be very helpful in the Kubernetes environment. Once we have the correct configurations, adding new nodes can be as simple as kubectl scale --replicas=n ....

Also, for building this image, we would require a separate Docerfile as we'll need to change config.properties so that loklak uses external cluster.

Right now, we've implemented the version where Elasticsearch and loklak server are on the same node and things are working fine. We've rolling updates functional and messages are retained in the persistent storage. This image can be used by people who want to host their own loklak instance.

switching off the dump generation (that must be implemented with a flag).

This will not be happening for other servers other than api.loklak.org, right?
Should I create an issue for this?

[singhpratyush]

Also, we can have development and master sharing the same data (ES index) but serving on different loklak API versions and URLs.

[niranjan94]

Also, we can have development and master sharing the same data but serving on different loklak API versions

That is not right. What if the schema of data changes in dev for some reason ? That'll affect the master too since it'll be running on a different version.

[singhpratyush]

@niranjan94: I think you are right (no mapping version for ES(?)). In this case, development can also be one of the

people who want to host their own loklak instance