web-dev-qa-db-fra.com

Configurer Apache sur un haricot élastique

Je développe avec Django sur élastique beanstalk et je veux apporter deux modifications à la configuration d'Apache:

1. redirigez www.domain.com vers domain.com

2. rediriger http://domain.com vers https://domain.com

Je n'ai pas d'expérience avec la configuration d'Apache, la recherche sur Google m'a donné l'idée que je devrais mettre RewriteRules dans le fichier .htaccess.

exemple: Comment forcer https sur Amazon élastique beanstalk sans échouer le bilan de santé

Je n'ai pas trouvé d'instructions sur la façon de le faire avec la configuration élastique de haricot magique (.ebextensions), j'ai essayé de simplement mettre un fichier .htaccess dans mon classeur racine et de le déployer, mais cela n'a pas fonctionné.

Est-ce que quelqu'un sait comment il est possible d'ajouter les règles de réécriture dans le haricot élastique?

22
Dan Bolofe

c'est une solution facile

  1. ssh dans votre instance EC2
  2. copiez le contenu de /etc/httpd/conf.d/wsgi.conf dans un fichier local appelé wsgi.conf qui sera placé dans le dossier de base de votre application
  3. Modifiez la version locale de wsgi.conf et ajoutez les règles de redirection suivantes dans les balises <VirtualHost> </ VirtualHost>

    RewriteEngine On
    RewriteCond %{HTTP:X-Forwarded-Proto} !https
    RewriteRule !/status https://%{SERVER_NAME}%{REQUEST_URI} [L,R=301]
    
  4. Modifiez le "/ status" sur la page que vous utilisez comme bilan de santé page.

  5. Sauvegardez le fichier
  6. Modifiez votre fichier <app> .conf dans votre répertoire. ebextensions pour ajouter une commande de conteneur pour copier cette version de wsgi.conf sur la version d'Amazon

    container_commands:
    01_syncdb:
      command: "Django-admin.py syncdb --noinput" leader_only: true
    02_collectstatic:
      command: "Django-admin.py collectstatic --noinput"
    03_wsgireplace:
      command: 'cp wsgi.conf /etc/httpd/conf.d/wsgi.conf'
    ...
    
  7. Déployez le code.

  8. La version déployée de wsgi.conf dans /etc/httpd/conf.d/wsgi.conf inclura désormais les règles de redirection nécessaires.

Cela devrait fonctionner et le fichier sera correctement mis à jour pour chaque déploiement. La seule chose à surveiller est que si Amazon modifie le contenu de son fichier wsgi.conf de base à l'avenir, votre copie risque de ne plus fonctionner.

Source: rickchristianson

6
gusgard

Ayant www.example.com aller à example.com peut être fait avec un CNAME dans DNS si vous ne vous souciez pas que ce soit réellement une redirection. Si vous avez besoin d'une redirection, vous pouvez l'ajouter à la configuration Apache ci-dessous. Le point principal de cette réponse est de détailler comment vous modifiez la configuration d'Apache sur Elastic Beanstalk (car faire cela correctement n'est pas très simple).

Cette réponse suppose que vous avez déjà activé https dans le groupe de sécurité de l'équilibreur de charge, ajouté le certificat SSL à l'équilibreur de charge, ajouté 443 aux ports transmis par l'équilibreur de charge et pointé votre nom de domaine vers l'environnement Elastic Beanstalk avec Route 53 (ou service DNS équivalent).

Tout ce que vous avez à faire est d'ajouter ce qui suit à l'un de vos .conf fichiers dans le .ebextensions répertoire de votre projet :

files:
    "/etc/httpd/conf.d/ssl_rewrite.conf":
        mode: "000644"
        owner: root
        group: root
        content: |
            RewriteEngine On
            <If "-n '%{HTTP:X-Forwarded-Proto}' && %{HTTP:X-Forwarded-Proto} != 'https'">
            RewriteRule (.*) https://%{HTTP_Host}%{REQUEST_URI} [R,L]
            </If>

Explication

C'est assez simple à l'extérieur d'Elastic Beanstalk. On ajoute généralement une règle de réécriture Apache comme celle-ci:

RewriteCond %{HTTPS} off
RewriteRule (.*) https://%{HTTP_Host}%{REQUEST_URI}

Ou, si derrière un équilibreur de charge, comme nous le sommes dans ce cas:

RewriteCond %{HTTP:X-Forwarded-Proto} !https
RewriteRule (.*) https://%{HTTP_Host}%{REQUEST_URI} [R,L]

Cependant, ces configurations ne fonctionnent que dans un <VirtualHost> bloquer. Changer le RewriteCond en <If> le bloc lui permet de fonctionner correctement en dehors d'un <VirtualHost> block, ce qui nous permet de mettre dans un fichier de configuration Apache autonome. Notez que la configuration standard d'Apache sur CentOS (y compris la configuration sur ElasticBeanstalk) inclut tous les fichiers correspondant à /etc/httpd/conf.d/*.conf, qui correspond au chemin du fichier où nous stockons ce fichier.

Le -n '%{HTTP:X-Forwarded-Proto}' une partie de la condition l'empêche de rediriger si vous n'êtes pas derrière un équilibreur de charge, ce qui vous permet d'avoir une configuration partagée entre un environnement de production avec un équilibreur de charge et https, et un environnement intermédiaire qui est une instance unique et n'a pas https. Ce n'est pas nécessaire si vous utilisez des équilibreurs de charge et https sur tous vos environnements, mais cela ne fait pas de mal de l'avoir.

Mauvaises solutions que j'ai vues

J'ai vu beaucoup de mauvaises solutions à ce problème, et il vaut la peine de les parcourir pour comprendre pourquoi cette solution est nécessaire.

  1. Utilisez Cloudfront: Certaines personnes suggèrent d'utiliser la configuration Cloudfront non mise en cache devant Elastic Beanstalk pour effectuer la redirection HTTP vers HTTPS. Cela ajoute un tout nouveau service (ajoutant ainsi de la complexité) qui n'est pas exactement approprié (Cloudfront est un CDN; ce n'est pas le bon outil pour forcer HTTPS sur du contenu intrinsèquement dynamique). La configuration Apache est la solution normale à ce problème et Elastic Beanstalk utilise Apache, c'est donc la voie à suivre.

  2. SSH sur le serveur et ...: C'est complètement antithétique au point d'Elastic Beanstalk et a tellement de problèmes. Toute nouvelle instance créée par mise à l'échelle automatique n'aura pas la configuration modifiée. Aucun environnement cloné n'aura la configuration. N'importe quel nombre d'un ensemble raisonnable de changements d'environnement effacera la configuration. C'est juste une si mauvaise idée.

  3. Remplacez la configuration Apache par un nouveau fichier: Cela entre dans le bon domaine de la solution mais vous laisse avec un cauchemar de maintenance si Elastic Beanstalk change des aspects de la configuration du serveur (ce qu'ils peuvent très bien faire). Voir également les problèmes dans l'élément suivant.

  4. Modifiez dynamiquement le fichier de configuration Apache pour ajouter quelques lignes: C'est une idée décente. Le problème est que cela ne fonctionnera pas si Elastic Beanstalk change jamais le nom de leur fichier de configuration Apache par défaut, et que ce fichier peut être écrasé quand vous vous y attendez le moins: https://forums.aws.Amazon .com/thread.jspa? threadID = 163369

51
Zags

Juste pour référence pour les autres, en utilisant solution de Zags pour rediriger non www vers www, ajoutez ceci à votre .ebextensions/your_file.config:

files:
    "/etc/httpd/conf.d/www_rewrite.conf":
        mode: "000644"
        owner: root
        group: root
        content: | 
            RewriteEngine On
            <If "'%{HTTP_Host}' !~ /^www\./">
            RewriteRule ^(.*)$ http://www.%{HTTP_Host}%{REQUEST_URI} [R=301,L]
            </If>
2
Nad