To migrate from a cloud mitter.io account to an on-prem solution, roughly the following steps need to be followed:
Host an instance of mitter on-prem using your deployment stack (in this walkthrough, we will use docker compose)
Make your instances reachable from the outside world
Migrate all the data from your cloud account to the on-prem account
Replace all endpoints that your services/apps were using to the new endpoints you have configured
For getting a reachable endpoint, you'll most probably need a domain that points to wherever you have hosted mitter. A general overview of how mitter.io on docker works is provided on the mitter.io on docker page. Do note that the image used on that page is not suitable for production deployments, as it bundles all services in a single container making replications and horizontal scaling that much difficult.
The configuration is not expected to work by just copy-pasting the file as-is. It is there to give a reference for your implementation.
In the example above, it is assumed that you are hosting your postgres database separately. For servicing real-world loads, we would recommend using CloudSQL or AWS RDS or a similar managed postgres service. If you want to run your own db, a docker container similar to the following will work:
Make sure you edit the username and password values for all running services in the first 3 sections of the file. They are then referenced in the CENTRAL_APPLICATION_CONFIG section of the configuration.
If you wish to continue running the mitter container with the dashboard enabled, then you should ideally not expose the dashboard port (in this example 11902) to the outside world or the public internet. We would strongly recommend using either using an ssh tunnel or similar proxy mechanisms to access the dashboard. In supernova installs, the dashboard runs without authentication (as you would've expected on your cloud hosted account). In case you wish to access it using a public address, then you can enable basic auth with a username/password that can be specified as on line no. 147 / 148 in the snippet above.
Please do review the mount point of the /data volume in this docker compose installation. All media/images etc. get stored on this location - you would need to ensure adequate capacity as per your needs.
Making your instance reachable
While this will greatly differ from installation to installation, a sample of how a machine running the docker compose shown above can use nginx to make these services accessible is as follows
server {
client_max_body_size 10M;
server_name mitter.your-host.com;
location / {
proxy_pass http://localhost:11901;
}
listen [::]:443 ssl;
listen 443 ssl; # managed by Certbot
ssl_certificate /etc/letsencrypt/live/<ssl-cert-directory>/fullchain.pem; # managed by Certbot
ssl_certificate_key /etc/letsencrypt/live/<ssl-cert-directory>/privkey.pem; # managed by Certbot
include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot
}
server {
server_name mitter-dashboard.your-host.com;
location / {
proxy_pass http://localhost:11902;
}
listen [::]:443 ssl;
listen 443 ssl; # managed by Certbot
ssl_certificate /etc/letsencrypt/live/<ssl-cert-directory>/fullchain.pem; # managed by Certbot
ssl_certificate_key /etc/letsencrypt/live/<ssl-cert-directory>/privkey.pem; # managed by Certbot
include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot
}
server {
server_name mitter-weaver.your-host.com;
location / {
proxy_pass http://localhost:7180;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
proxy_read_timeout 86400;
}
listen [::]:443 ssl;
listen 443 ssl; # managed by Certbot
ssl_certificate /etc/letsencrypt/live/<ssl-cert-directory>/fullchain.pem; # managed by Certbot
ssl_certificate_key /etc/letsencrypt/live/<ssl-cert-directory>/privkey.pem; # managed by Certbot
include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot
}
server {
if ($host = mitter.your-host.com) {
return 301 https://$host$request_uri;
} # managed by Certbot
if ($host = mitter-dashboard.your-host.com) {
return 301 https://$host$request_uri;
} # managed by Certbot
if ($host = mitter-weaver.your-host.com) {
return 301 https://$host$request_uri;
} # managed by Certbot
listen 80 default_server;
listen [::]:80 default_server;
server_name mitter-weaver.your-host.com mitter.your-host.com mitter-dashboard.your-host.com
return 404; # managed by Certbot
}
Migrating your data
By now, you would have received your entire data from the cloud account on your email. If you haven't, please reach out to support@mitter.io. To get started on the data migration, you will need three things:
An installation of psql on the some machine that can reach your postgres instance. This psql cli must be compatible with Postgres 9.6.
Your data has already been transformed to run with mitter supernova builds, and all of your application ids, application keys, settings, user ids, message ids are preserved. All of your existing apps and APIs will continue to work as long as the API endpoints are modified. However, any user login information will not be persisted, and all of your users will have to fetch new authentication tokens. This is due to the fact that user tokens are signed by mitter's private key during issue and that data can longer continue to function without us distributing mitter's private key itself. (This is the 'signing-key' part of the configuration specificed in the docker-compose file).
Migrating your apps
To migrate your apps, all you will need to do is:
Modify the endpoint to which your API calls were being made to (i.e. you will have to change it from https://api.mitter.io to https://mitter.your-host.com or a similar domain name you have chosen to host these services on)
Do note that you will have to use some form a web server or a load balancer to expose your docker containers to the public internet via a domain name. It is not recommended to directly expose your docker ports from your machines.
For apps, you will require all of your users to re-login and fetch new tokens. If they have registered any prior FCM delivery endpoints, they will continue to work without any changes from your side.
Depending on which SDK you are using, please refer to the SDKs individual page for instructions on how to specify a different endpoint
Troubleshooting
If any of the containers refuse to start, or they are not working as expected, you can check the logs to troubleshoot these errors. To get a list of containers running, you could run
docker ps -a
If you used a docker compose file similar to the one above, you'd be seeing container names that begin with mitter_. Against these containers you should also be able to see if the containers are in a healthy or an unhealthy state. To check the logs, you can simply use:
