Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

As of https://github.com/containous/traefik/pull/1257 it is currently not possible to have both the frontend and the backend in the same container except you make sure your api is reachable under containername/api. (Please be aware that Traefik has different uses for the terms frontend and backend!)

Frontend

Starting with the visual (and easier part). You will have to modify (or tell someone to modify) the docker-compose.yml so it includes your frontend service. The docker-compose entry looks like this:

...

Please note the label "registry.modules". This tells the registry where to find the getModules.json. Your service should serve that file under that relative url, so in this case the registry would query "http://omsapplications-frontent:8086/getModules.json" (swarm-dns resolved). The getModules file provides information about the frontend entry:

Code Block
{
  "name": "OMS Applications",
  "code": "omsapplications",
  "pages": [{
    "name": "Applications",
    "code": "applications",
    "module_link": "all/applicationsController.js",
    "icon": "fa fa-ticket"
  }]
}

...

In this example, const baseUrl would end up being "http://localhost/services/applications/". This is injected by the registry and the core automatically, you do not have to care about this. And actually you also can not care about this, as the registry sets the url for you, based on what you put in the docker-compose.yml. Also you will find the name of your controller here, hint: .module('app.applications', []). If you fuck up this configuration, you will blow the complete frontend by activating your module until 

Jira Legacy
serverJIRA (oms-project.atlassian.net)
columnskey,summary,type,created,updated,due,assignee,reporter,priority,status,resolution
serverIdedf3f91b-210c-3cfc-933c-f8d8084c5f2c
keyCORE-22
 is implemented, so you will know when you put something wrong in here.

Backend

This is what lives inside the cloud and is only exposing an API to the client. You can write the backend in whatever language you want, but we recommend to choose node.js or php/laravel, as we have other services written in those languages and thus other people being able to help you and to maintain your code. Again, we first have to start off with adding a docker-compose.yml entry (or asking someone to do that for you):

...

  • X-Auth-Token: this is a token uniquely identifying a user. If you are in posession of this token, this is the preferred way to query other services as it prevents a privilege escalation. This is the case for all user-induced querys, meaning not cron and not startup but basically everything else. You are querying another service "on behalf" of that user, so you should also just have the rights of that user in the other service. You will get this token in the header of a user request, and if you don't that means the user didn't log in. If you want to check for authenticity of the x-auth-token, you will have to query the core (until 
    Jira Legacy
    serverJIRA (oms-project.atlassian.net)
    serverIdedf3f91b-210c-3cfc-933c-f8d8084c5f2c
    keyCORE-80
    ). How to query the core? Well, that's undocumented, have a lot of fun finding out! Hint: /api/getUserByToken and then add some weird headers and stuff.
  • X-Api-Key: This is a key issued by the registry for intraservice-communication. For the exact issuing, also have a look at Micro service - communication as it describes a intraservice-communication more in detail. To get an api-key, you will have to query the registry with an api-key (yes, another key). You will find the api-key (not the x-api-key) in the shared volume that you mounted in your docker-compose.yml entry auto-generated by the registry, in this example it is /usr/shared/new-api-key. Just send all the file contents to the registry and it will trust you to be a service actually running in the same cloud. That also means: don't fucking leak that one! If you happen to leak an x-api-key that's not too bad, as they expire after a day (yes they expire, your service will have to renew them), but please also try to avoid that.
    If you want to send a request authenticated by your x-api-key, simply add it to the headers field, and for the lulz also a field: 'X-Requested-With': 'XMLHttpRequest' (otherwise the core will not accept you).
    If you happen to receive a request which you want to authenticate by X-Api-Key, have a look at this api-call to the registry.

...