1. 05 Jul, 2018 1 commit
  2. 27 Jun, 2018 1 commit
    • BAIRE Anthony's avatar
      Add an auxiliary HTTP server (allgo.aio) for serving asynchronous requests · c5cd2bc1
      BAIRE Anthony authored
      There are two purposes:
      - implement server push (using long-lived HTTP requests) for:
          - sending status updates for the jobs and sandboxes
          - live-streaming of the job logs
      - have a really async implementation for pushing image manifests into
        the registry (the preliminary implementation in
        5451a6df was blocking)
      It is implemented with aiohttp.web (a lighweight HTTP framework,
      similar to what we can do with flask but asynchronously).
      The alternative would have been to use the django channels plugin, but:
      - it went through a major refactoring (v2) recently
      - it requires replacing unicorn with an ASGI server (daphne)
      - django-channels and daphne are not yet debian, and for the HTTP server
        i would prefer an implementation for which we have stable security
      (anyway this can be ported to django-channels later)
      The nginx config redirects the /aio/ path to this server (and the image
      manifests pushes too).
      The allgo.aio server interacts only with the nginx, reddis and django
      containers. It relies totally on the django server for authenticating
      the user and for accessing the mysql db (so there is no ORM).
      NOTE: in this design the django server has to trust blindly the requests
      coming from the allgo.aio server (for some endpoints). To prevent
      security issues, the nginx configuration is modified to set the header
      'X-Origin: nginx'. Thus django knowns who he can trust.
      This commits implements only the image pushs. Job updated and logs
      streaming will come in a later pull request.
  3. 13 Jun, 2018 2 commits
    • BAIRE Anthony's avatar
      add the reverse-proxy config for registry urls (/v2/) · 1e3477d8
      BAIRE Anthony authored
      - images manifest push/pull are routed through the django server
      - all other endpoints are routed directly to the registry
      On client-side the registry url is the is the same as the allgo server.
      The backend registry location is configured by the
      ALLGO_REGISTRY_PRIVATE_URL which is set to "http://{ENV}-registry"
      by default (i.e. 'http://dev-registry' in dev)
      Because the registry URL is configured at runtime (by the env
      var), the nginx config can no longer be static.
      /etc/nginc/conf.d/allgo.conf is generated at runtime
       (after loading the django config)
    • BAIRE Anthony's avatar
      Trust the X-Forwarded-* headers from the reverse proxy · d3a45dbc
      BAIRE Anthony authored
      This makes the config simpler, now that the reverse-proxy is required
      (because of the image push/pull endpoint routed through django)
  4. 19 Apr, 2018 1 commit
    • BAIRE Anthony's avatar
      fix the nginx config · cf0d22dd
      BAIRE Anthony authored
      - install django statics into /var/www at image build time
      - django now on port 8000 (django's default) instead of 4000
      - rename @allgo as @Django in nginx's config to decrease confusion
      - publish port 8080 in docker-compose
  5. 12 Apr, 2018 1 commit