9
votes

Détecter automatiquement l'environnement de développement interne / externe

Nous utilisons la fonction suivante pour détecter automatiquement si nous sommes sur une machine en interne ou sur un serveur en direct, puis choisissez les configurations appropriées pour différents composants: xxx

comme vous pouvez le voir seulement s'appuie sur la valeur http_host.

Bien sûr, si vous utilisez une sorte d'hôte virtuel localement comme Exemple.com, la fonction sera trompée.

y a-t-il d'autres moyens de tromper la fonction? et quelles autres variables / places pourrions-nous jeter un coup d'œil pour déterminer où nous sommes?


0 commentaires

5 Réponses :


1
votes

Créer et rechercher plus tard un fichier qui n'existe que sur le système de fichiers du serveur Live.

accordé, vos environnements devraient être aussi semblables que possible; Ce que je suggère, c'est quelque chose comme ceci: dans le répertoire / var / environnement /, ont un fichier nommé {devel | test | qa | stadification | Live}, en fonction du serveur que vous allez - alors vérifiez simplement le nom de fichier. < / p>

Bien sûr, vous devez exclure ce fichier à partir du contrôle de la version et de tout processus de construction que vous pourriez avoir.


3 commentaires

C'est une autre avenue. Plutôt que de créer un fichier (puis de me rappeler le fait), j'ai pensé à vérifier le système de fichiers pour des indices, tels que les répertoires de maison, etc., mais parfois, le système de fichiers de serveurs de production est identique au serveur de test.


En effet. Je voulais créer / var / environnemental / développement sur devel, / var / environnement / en direct sur Live, etc. Ces fichiers n'ont pas besoin d'avoir du contenu et ils ne doivent pas être utilisés pour rien de distinction des environnements. Édité ma réponse pour clarifier.


C'est comme ça que je suis allé avec mon projet le plus récent. J'ai simplement créé un fichier appelé développement.txt et le rechercher dans mon fichier config.php. C'est simple, explicite et ne nécessite aucune modification en dehors du répertoire de projet.



0
votes

Bien sûr, si vous utilisez un hôte virtuel localement comme exemple exemple.com, la fonction sera trompée.

Également si l'hôte n'est pas local mais utilise une carte VheckCard ou par défaut Vhost defn et l'utilisateur ajoute l'adresse IP au fichier d'hôtes localement.

Je recommanderais d'avoir un répertoire sur le chemin d'inclusion qui existe sur Live mais n'est pas répliqué là-bas et stockez simplement: xxx

ou xxx

si les deux env. Même serveur - Vous pouvez toujours le faire en définissant l'inclusion_path dans Apache config ou .htacaccess.

Ceci vous permet également de séparer des données spécifiques éventuellement sensibles - comme des hôtes de base de données / mots de passe et des touches d'encaction.

c.


1 commentaires

Nous pourrions simplement vérifier si un répertoire existait, par exemple le répertoire personnel de certains utilisateurs. Idée intéressante. Mais parfois, une mise en page de serveurs de production dédiée reflète le serveur de test interne.



16
votes

Définissez une variable d'environnement dans votre configuration d'hôte virtuelle Apache. C'est la façon dont le Zend framework le fait.

voir le Guide de démarrage rapide ZF pour un exemple (la section "Créer une hôte virtuelle".)

dans votre fichier httpd.conf ou un fichier .htaccess, mettre: xxx

Dans votre application, utilisez le Fonction getenv à Obtenir la valeur: xxx


11 commentaires

Parfois, la modification httpd.conf n'est pas autorisée. Avoir un fichier .htaccess contenant une valeur clé pour signifier l'environnement n'est pas automatique.


@ZAF - Pouvez-vous élaborer sur "Avoir un fichier .htaccess contenant une valeur clé pour signifier l'environnement n'est pas automatique"? Personnellement, je trouve que c'est la solution la plus élégante, mais les hôtes peuvent restreindre ce que vous pouvez faire dans le fichier .htaccess - est-ce ce que vous voulez dire?


@ZAF définissant une variable de .htaccess est aussi automatique que la vérification de la variable http_host ou l'ajout à la configuration principale (httpd.conf, etc.)


@ Andy / CEZ J'essaie de trouver une méthode sans modifier l'environnement que l'application vit. Pas aussi élégant que votre solution, mais c'est similaire, je pouvais simplement définir une variable dans la configuration des applications, mais je souhaite éviter de vous rappeler de faire une autre modification requise pour le déplacement des applications des tests à la production (et inversement). Http_host est "automatique" parce que vous n'avez rien à faire.


@zaf êtes-vous toujours sur un serveur * NIX?


@ZAF - OK, je vois ton point maintenant. J'essaie toujours de trouver des moyens de réduire les tâches de «maintenance» et de modifier les risques. Tout ce qui peut changer sans votre connaissance est un risque. Cela inclut le nom d'hôte, l'adresse IP, etc. Modification de l'environnement que votre application vit est quelque chose qui change uniquement avec vos connaissances - espérons-le parce que vous avez fait le changement! DHCP ou un administrateur réseau peut modifier l'adresse IP d'un serveur sans vous le dire. Comme vous l'avez déjà trouvé, un utilisateur peut tromper votre application en utilisant un nom d'hôte virtuel différent, un fichier sur le système de fichiers peut être supprimé ou en quarantaine.


Continuer mon commentaire précédent ... La solution de fichier de configuration est une autre option qui conserve mon mantra "sans risque", tant que vous vous souvenez de la mettre à jour chaque fois que vous publiez une mise à jour de votre application, de sorte que ce n'est pas aussi résistant que le variable d'environnement. Une raison pour laquelle vous êtes si contre l'approche variable de l'environnement? Vous souhaitez modifier l'environnement de l'application d'une manière ou d'une autre, il sait qu'il fonctionne en direct par opposition à Dev, mais vous dites que vous ne voulez pas modifier l'environnement.


@Cez nop. Ajouter Apple et MS au mix.


@Andy, je ne veux pas modifier l'environnement des applications ou son code de quelque manière que ce soit. La fonction actuelle Devislocal () l'obtient et nous permet la liberté de télécharger des applications à un environnement de production sans avoir à définir un drapeau quelque part en disant que l'environnement est dans lequel l'environnement. Bien sûr, nous avons toujours des configurations pour chaque environnement, mais elles sont activées en fonction de Si Devislocal (). Pour la plupart des applications, il s'agit d'un aspect critique de la mission et je préférerais que le code déciderait plutôt que quelqu'un se souvenir de mettre à jour un paramètre.


@ZAF - Vous ne seriez à faire qu'une fois lorsque l'application est d'abord installée. Il suffit de remplacer le code dans votre fonction existante avec un chèque de la variable d'environnement et vous pouvez alors oublier qu'il existe si vous le souhaitez. Vous pouvez également mettre votre fonction dans une bibliothèque et l'utiliser pour plusieurs applications - tout ce que vous avez à faire est de définir la variable Application_env lorsque vous installez l'application et vous avez terminé. Effort minimum. 100% réutilisable. Aucun risque de compromis. Comme vous l'avez déjà signalé, votre fonction existante peut être dupe, et vous devez redéployer l'application si le nom d'hôte change.


@ZAF Je ne suis toujours pas clair pourquoi vous ne pouvez pas la définir à la "production" comme défaut et utiliser la méthode que Andy et j'ai suggéré de remplacer lors du test ou du développement. En ce qui concerne le lancement d'autres variables, qu'en est-il de l'utilisation de Shell_Exec () pour appeler la fonction System HostName?



12
votes
'127.0.0.1' == $_SERVER["REMOTE_ADDR"]
This will never evaluate as TRUE on your live system. :)

9 commentaires

Il ne pourra également pas accéder à votre serveur local avec une adresse IP face au public, soit.


+1 pour mentionner la vérification de l'adresse IP. Andy a raison, nous devrons également ajouter les gammes IP réservées aux intranets. Est-ce que cela fonctionnera alors?


@ZAF: Oui, bien sûr. Andy a mal compris comme une solution complète, alors que je voulais juste montrer le concept général. Peut-être que je dois être plus explicite à l'avenir ...: - /


@toscho Vous devez être plus explicite sinon vous serez frappé par la horde. Vous vivez et apprenez.


@toscho - Vous devez être explicite, soit en adaptant votre réponse à la solution exacte, soit en expliquant le concept plus loin - par exemple. "Ajoutez des contrôles supplémentaires pour toutes les adresses IP attribuées au serveur." Personnellement, cependant, je trouve que cela soit une solution «à haute maintenance», en particulier si les adresses IP du serveur sont gérées par DHCP et DNS dynamique - non idéal, mais c'est possible et je l'ai déjà vu dans quelques environnements.


@toscho: ssh live-serveur -L80: 127.0.0.1: 80 créera un tunnel sur le serveur (faux positif); En outre, et si vous accédez à l'hôte sur IPv6 (faux négatif)?


J'utilise wamp. Je suppose que, à cause de IPv6, le code ne fonctionne pas tel quel, le concept fonctionne parfait. Ceci est le code modifié que j'utilise: si (($ _ Server ["Remote_addr"] == '127.0.0.1') || ($ _Server ["Remote_addr"] == ':: 1')) {$ environnement = "développement"; } else {$ environnement = "production"; }


Vous devez faire attention aux scripts CLI essayant de détecter l'environnement avec cela et si un script local initie une demande HTTP localement, votre Remote_Addr sera en fait 127.0.0.1.


^^^ Qu'est-ce que @Philix a dit. Cela ne fonctionnera pas lorsque le distant_addr est NULL I.E. Lorsque le script est exécuté via la ligne de commande.