Deploying Kotahi in Google Cloud

Installing and Deploying Kotahi
1

Questions about installing and deploying Kotahi in Google Cloud Plattform

I’m trying to install Kotahi and deploy it in Google Cloud Plattform. Has anybody done this before that can share some tips?

At the moment I am a bit stuck in converting the Docker compose file into instructions for the kubernetes and creating the Docker image for the google artifact registry. Any help is greatly appreciated.

2

hi, Did you get anywhere? We havent been using this channel but now considering resurrecting it.

3

Hello Adam,

I tried but the learning curve was too steep for me. I decided to first try by creating a virtual machine in Google Cloud and following the instructions provided by Kotahi.

4

Do you need any further help?

5

Dear Adam,

Yes, please. Some help would be very appreciated.

I have been learning about GCP and the steps I followed were:
I created the VM,
added docker and docker compose.
I cloned the repo.
sourced the example .env file.
docker-compose build
docker-compose up
and changed the firewall in gcp to allow traffic to the port 4000 of the vm.

The service seems to be running and in the browser I see the name kotahi and I get a message in the browser page saying that there is a communication error.

In the console I see the following errors repeating:

client-1 | [HPM] Error occurred while trying to proxy request /graphql from client:4000 to http://server:3000 (ECONNREFUSED) (Errors | Node.js v21.6.1 Documentation)

Am I missing any step in the configuration for running the development environment?

[p.s: I wanted to paste the whole console history of when I run docker-compose up but there is an error saying that I am not allowed to put more than 2 links being a new user]

6

Hi there.

When you’re using the development compose file (ie. docker-compose.yml), compose will create a network where client and server are valid hostnames. This means that within that network (but only within that network) the client can make a call to server:3000. To be able to have the client and server communicate with each other outside of that network you might want to change the variables that are passed to the containers via the compose file. eg. The client’s SERVER_HOST might need to be 111.111.111.111 or whatever your public url is instead of server. Hope this helps.

7

As a side note, we’ll be offering prebuilt production images for kotahi’s client and server respectively in the near future (along with some documentation for deploying kotahi), but I can’t give you an exact timeline atm.

8

Hello dear Yannis,

Thank you very much for your answers. I am at the moment trying to implement your solution. A further question I have is, should I change only the docker-compose.yml or do I also need to change the .env file that I source?
If I need to change the env file (for the first test run) can I leave the CLIENT_HOST as 0.0.0.0 or do I need to change that one as well to the public URL?

Thank you!

9

should I change only the docker-compose.yml or do I also need to change the .env file that I source

Either really.

  • You can have a hardcoded value (eg. MY_VAR=test).
  • Or have it read the value from .env (eg. MY_VAR=${MY_VAR}, where MY_VAR is a variable in the .env file) – docker compose will read the .env file automatically.
  • Or have it check the .env file and fall back to a default value if it doesn’t find anything: MY_VAR=${MY_VAR:-default}

Controlling it through the .env file is preferrable as it would avoid conflicts when the time comes to pull an updated version of the code. But at the end of the day, the only thing that really matters is the value that gets passed on from the compose file to the docker container itself.

If I need to change the env file (for the first test run) can I leave the CLIENT_HOST as 0.0.0.0 or do I need to change that one as well to the public URL?

If you’re running the docker-compose.yml file, I think you need to leave the client value set to 0.0.0.0 on the client service. This is a webpack dev server peculiarity, but you don’t necessarily need to worry too much about the internals of it.

The important parts are two:

  • The client container needs to know where to find the server, so that it can communicate with it. This is controlled by the SERVER_ variables in the client service.
  • The server needs to know the client, so that it can be whitelisted for cors (so that you don’t get the cross-origin request denied errors in the browser). This is controlled by the CLIENT_ variables in the server service.

Hope that helps!

10

Btw, we have some internal docs for docker and docker compose. Feel free to use them.
Other Guides / docker - Page ⋅ Storybook (coko.foundation)
Other Guides / docker-compose - Page ⋅ Storybook (coko.foundation)

11

@yannis Thank you very much. I simply changed the .env file variable SERVER_HOST to my external IP and I can already see the service in my browser.
Thanks again for your clear and quick response.

12

good to hear! :+1:

14

Dear @yannis, Sometime ago you mentioned that you will be offering a prebuilt production image for servers. Do you have any news about this?

Also, the files that you shared sometime ago in this thread about docker and docker compose in Storybook are not accessible anymore. Could it be possible to access them again?

Thanks for your help,

15

Dear @yannis, Sometime ago you mentioned that you will be offering a prebuilt production image for servers. Do you have any news about this?

Yes there is. We’re hoping to get it merged within the month.

Also, the files that you shared sometime ago in this thread about docker and docker compose in Storybook are not accessible anymore. Could it be possible to access them again?

Yeah sorry about that. There was a problem with our deployment setup and the site went down. I’ll bring it back up when I get the chance. In the meantime, you can run the docs repo locally if you want.

1 Like
16

Thank you very much dear @yannis !