Skip to content

Static file mounting#3

Merged
rgbkrk merged 14 commits into
masterfrom
static_files
Nov 18, 2014
Merged

Static file mounting#3
rgbkrk merged 14 commits into
masterfrom
static_files

Conversation

@rgbkrk

@rgbkrk rgbkrk commented Nov 18, 2014

Copy link
Copy Markdown
Member

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

rgbkrk commented Nov 18, 2014

Copy link
Copy Markdown
Member Author

Alright, this is ready for review!

@rgbkrk

rgbkrk commented Nov 18, 2014

Copy link
Copy Markdown
Member Author

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

Copy link
Copy Markdown
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
Copy Markdown
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
Copy Markdown
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
Copy Markdown
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
Copy Markdown
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