Tenho pensado em tentar conservar instâncias do Unicorn que consomem muita memória configurando meu nginx externo (que já tenho para servir a página de manutenção 502 e para atribuir corretamente endereços IPv6) para também atender solicitações de imagens; com a intenção de obter grande parte do valor de movê-las para o S3 (ou serviço de objetos compatível), mas ainda mantendo o site autocontido no meu servidor. (Isso não moveria outros ativos do site para fora dos Unicorns, mas esses são bem cacheados de página para página, então isso representa um custo total muito menor nos Unicorns.)
Assim como apontar o nginx externo para um socket em /var/discourse/shared, eu serviria /uploads a partir de /var/discourse/shared/$container/uploads.
Não vejo menção aqui no meta de que alguém tenha feito isso, embora meu conhecimento de busca possa ser fraco. Estou deixando passar algum motivo pelo qual isso não funcionaria ou funcionaria mal na prática?
Se você deseja ajudar seus unicórnios, uma coisa que realmente ajuda é habilitar um CDN para o seu Discourse, pois isso armazenará em cache os poucos ativos servidos nos unicórnios, como as folhas de estilo.
Eu apostaria que habilitar o cache no nginx externo traria o mesmo benefício em relação ao carregamento dos unicórnios, sem precisar configurar um CDN. Vejo cabeçalhos de controle de cache em todos os ativos de JavaScript, então talvez eu tente isso…
… bem, vejo que o nginx interno já está usando proxy_cache com validade de 7 dias para solicitações sem erro:
location ~ ^/(svg-sprite/|letter_avatar/|letter_avatar_proxy/|user_avatar|highlight-js|stylesheets|theme-javascripts|favicon/proxied|service-worker) {
...
# note x-accel-redirect can not be used with proxy_cache
proxy_cache one;
proxy_cache_key "$scheme,$host,$request_uri";
proxy_cache_valid 200 301 302 7d;
proxy_cache_valid any 1m;
proxy_pass http://discourse;
break;
}
Como um CDN ajuda com os unicórnios nesse caso? Vejo stylesheets nessa lista.