Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Static file mounting #3

Merged
merged 14 commits into from
Nov 18, 2014
Merged

Static file mounting #3

merged 14 commits into from
Nov 18, 2014

Conversation

rgbkrk
Copy link
Member

@rgbkrk rgbkrk commented Nov 18, 2014

This begins the adventure of both:

  • Sticking nginx in a container
  • Mounting static assets from the userland container to the nginx container

This also tosses the static.tar legacy file.

@rgbkrk rgbkrk changed the title [WIP] Static file mounting Static file mounting Nov 18, 2014
@rgbkrk
Copy link
Member Author

rgbkrk commented Nov 18, 2014

Alright, this is ready for review!

@rgbkrk
Copy link
Member Author

rgbkrk commented Nov 18, 2014

This works! It's alive!

rgbkrk added a commit that referenced this pull request Nov 18, 2014
@rgbkrk rgbkrk merged commit ff9dee1 into master Nov 18, 2014
@rgbkrk rgbkrk deleted the static_files branch November 18, 2014 08:48
- name: nginx
apt: name=nginx state=present
- name: pull docker image for user containers
command: docker pull {{ tmpnb_image }}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There's a trick you can use to register whether or not a newer image was actually pulled, which can save you extraneous restarts:

- name: pull the latest docker build
  command: docker pull myimage
  register: someimage
  changed_when: someimage.stdout.find('Downloaded newer image') != -1
  sudo: yes

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmmm, with that I'll need to start a new nginx container too then (so that it links to new static assets).

I'm not as worried about upgrading nodes in place since we can end up with a version mismatch here:

  1. User creates a notebook server
  2. (Some) assets are cached by their browser
  3. We upgrade the static files served by nginx
  4. They open a link to their server on a different browser, computer, etc.
  5. The notebook now uses different js/css than is served by nginx

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmmm, with that I'll need to start a new nginx container too then (so that it links to new static assets).

Yes, the idea is that later you can do:

- name: Restart nginx
  docker: image=nginx state=restarted
  when: someimage | changed

I'm not as worried about upgrading nodes in place since we can end up with a version mismatch here

Oh, right. I really wish the assets could be hash-fingerprinted, it would solve a lot of problems like this one...

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Even if we hash-fingerprint them, we're still serving a specific set from nginx rather than what any given container is necessarily running.

If we wanted to though, we could finish up the piece from tmpnb's tornado app that handles static asset serving. Right now it only serves static.tar when it could serve static for each path (making sure to key on image id).

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The better option, that I still haven't tried, is to try loading IPython's static assets over a CDN.

This involves setting the static_url setting for IPython's tornado server.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants