1. 09 Apr, 2020 1 commit
  2. 02 Apr, 2020 2 commits
  3. 23 May, 2019 2 commits
  4. 21 May, 2019 1 commit
    • sebastien letort's avatar
      django-nginx conf file has been reordered, and API location has been slightly... · 732f5c1c
      sebastien letort authored
      django-nginx conf file has been reordered, and API location has been slightly rewritten with inner locations.
      
      Here we conserved the CORS principles and make them used to all API, datastore included.
      Note that trying to get a file with the api (api/v1/datastore/...) will return a 404.
      -> but the end user has no reason to known this path.
      732f5c1c
  5. 02 May, 2019 1 commit
  6. 17 Sep, 2018 1 commit
  7. 31 Jul, 2018 1 commit
  8. 05 Jul, 2018 1 commit
  9. 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
        updates
      
      (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.
      c5cd2bc1
  10. 13 Jun, 2018 1 commit
    • 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)
      1e3477d8