A página de boas-vindas do Nginx retorna

Question

Estou executando o Nginx em uma instância do EC2. Eu tenho uma página da Web instalada no padrão /usr/share/nginx/html dir. Notei que, se eu fizer uma AMI dessa instância do EC2 e uma nova instância do EC2 usando essa AMI, o site de boas-vindas do Nginx padrão (isto é, index.html, 404.html, etc.) será restaurado e substituirá o site existente onde os arquivos são os mesmos. Eu posso dizer isso fazendo um git status nesse diretório e ver que eles foram adicionados.

Isso é um pouco trabalhoso porque estou executando um produto SaaS na instância do EC2, e fazer com que os clientes vejam a página de boas-vindas do Nginx parece um pouco não profissional.

Minha pergunta é: o que poderia estar causando isso?

Aqui está meu nginx.conf :

# For more information on configuration, see:
#   * Official English Documentation: http://nginx.org/en/docs/
#   * Official Russian Documentation: http://nginx.org/ru/docs/

user  nginx;
worker_processes  1;

error_log  /var/log/nginx/error.log;
#error_log  /var/log/nginx/error.log  notice;
#error_log  /var/log/nginx/error.log  info;

pid        /var/run/nginx.pid;


events {
    worker_connections  1024;
}


http {
    include       /etc/nginx/mime.types;
    default_type  application/octet-stream;

    log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
                      '$status $body_bytes_sent "$http_referer" '
                      '"$http_user_agent" "$http_x_forwarded_for"';

    access_log  /var/log/nginx/access.log  main;

    sendfile        on;
    #tcp_nopush     on;

    #keepalive_timeout  0;
    keepalive_timeout  65;

    #gzip  on;

    # Load modular configuration files from the /etc/nginx/conf.d directory.
    # See http://nginx.org/en/docs/ngx_core_module.html#include
    # for more information.
    include /etc/nginx/conf.d/*.conf;

    #server {
    #    listen       80;
    #    server_name  *.xxx.com;
    #    return       301 https://$host$request_uri;
    #}

    server {
        listen        80;
        listen        443 default ssl;
        server_name  *.xxx.com;

        if ($http_x_forwarded_proto = "http") {
            return 301 https://$host$request_uri;
        }

        ssl_certificate /etc/pki/tls/certs/process.st.crt;
        ssl_certificate_key /etc/pki/tls/private/process.st.key;
        ssl_protocols SSLv3 TLSv1;
        ssl_ciphers ALL:!aNULL:!ADH:!eNULL:!LOW:!EXP:RC4+RSA:+HIGH:+MEDIUM;

        #charset koi8-r;

        #access_log  /var/log/nginx/host.access.log  main;

        location / {
            root   /usr/share/nginx/html;
            index  index.html index.htm;

            # Disable cache (for now).
            add_header Cache-Control no-cache;
        }

        # redirect server error pages to the static page /40x.html
        #
        error_page  404              /404.html;
        location = /40x.html {
            root   /usr/share/nginx/html;
        }

        # redirect server error pages to the static page /50x.html
        #
        error_page   500 502 503 504  /50x.html;
        location = /50x.html {
            root   /usr/share/nginx/html;
        }

        # proxy the PHP scripts to Apache listening on 127.0.0.1:80
        #
        #location ~ \.php$ {
        #    proxy_pass   http://127.0.0.1;
        #}

        # pass the PHP scripts to FastCGI server listening on 127.0.0.1:9000
        #
        #location ~ \.php$ {
        #    root           html;
        #    fastcgi_pass   127.0.0.1:9000;
        #    fastcgi_index  index.php;
        #    fastcgi_param  SCRIPT_FILENAME  /scripts$fastcgi_script_name;
        #    include        fastcgi_params;
        #}

        # deny access to .htaccess files, if Apache's document root
        # concurs with nginx's one
        #
        #location ~ /\.ht {
        #    deny  all;
        #}
    }


    # another virtual host using mix of IP-, name-, and port-based configuration
    #
    #server {
    #    listen       8000;
    #    listen       somename:8080;
    #    server_name  somename  alias  another.alias;

    #    location / {
    #        root   html;
    #        index  index.html index.htm;
    #    }
    #}


    # HTTPS server
    #
    #server {
    #    listen       443;
    #    server_name  localhost;

    #    ssl                  on;
    #    ssl_certificate      cert.pem;
    #    ssl_certificate_key  cert.key;

    #    ssl_session_timeout  5m;

    #    ssl_protocols  SSLv2 SSLv3 TLSv1;
    #    ssl_ciphers  HIGH:!aNULL:!MD5;
    #    ssl_prefer_server_ciphers   on;

    #    location / {
    #        root   html;
    #        index  index.html index.htm;
    #    }
    #}

}

Passos que fiz para criar a imagem AMI base.

1. Console do AWS EC2: inicie a instância com o Amazon Linux de 64 bits.
2. SSH no exemplo: sudo yum install git , sudo yum install nginx .
3. Edite o /etc/nginx/nginx.conf para o acima.
4. Copie todos os certificados SSL necessários.
5. Excluir a página padrão em /usr/share/nginx/html .
6. Clone o repositório do Git em /usr/share/nginx/html .

Agora eu crio a imagem:

1. ec2-create-image $INSTANCE_ID --name base .
2. Console do AWS EC2: inicie a instância usando a AMI "base".
3. Quando é inicializado, ele tem a página de boas-vindas novamente junto com a página que tirei do git, mas as páginas do Nginx substituíram os arquivos com o mesmo nome.

Answer 1

Eu só aproveitei para tentar reproduzir esse problema e não consegui.

Eu lancei o mais recente Amazon Linux AMI.

Após o login, instalei git e nginx via yum, movi /usr/share/nginx/html para /usr/share/nginx/orig-html , copiei um repo html em usr/share/nginx/html e testei que o novo repo está visível, não na página de teste.

Depois, usei o AWS Console para "Criar imagem" da instância de trabalho.

Quando a imagem da AMI foi concluída, lancei outra instância da minha AMI personalizada e confirmei que o site que eu havia instalado estava funcionando, não o padrão.

Então, eu acho que eu perguntaria se você estava criando a imagem corretamente, esperando que o instantâneo fosse concluído antes de iniciar outra instância usando o novo ID da AMI.

    

Answer 2

muito provavelmente, você colocou seu código github no diretório errado (isto é, não nginx doc root), e assim o nginx é o default para a saudação padrão que vem com ele.

parece que você usa páginas html estáticas, então isso é muito simples.

apenas cole o seu /etc/nginx/nginx.conf (e todos os arquivos conf incluídos).

EDIT :: depois de ler mais atentamente a questão, parece que existe um processo de inicialização que está redefinindo seu conf do nginx para a configuração padrão. novamente, cole seu arquivo conf e podemos ajudar mais. quando você reiniciar, você notou mudanças neste arquivo? qual é o timestamp? mesmo que o boot?

EDIT2: tente usar um ami diferente, como o oficial centos 6.4 ami

It does not happen on reboot, only when I create a new EC2 and use the AMI.

ou pelo menos nos dê mais detalhes sobre o que você está lançando. as chances são, esse comportamento estranho não vai acontecer com centos oficial ami

    

Answer 3

Aqui está o meu palpite: o site padrão do Nginx está sendo posto em prática e substituindo o seu site. Aqui estão algumas coisas para experimentar:

• (sudo) nxdissite padrão
(sudo) rm / etc / nginx / sites-enabled / default