Voici mon scénario:
A est un serveur de provisioning et B est un client. Chaque fois qu'il y a une modification de la configuration de B, elle télécharge le fichier de configuration approprié à A.
Je travaille comme ingénieur automatisé pour l'automatiser. L'un des scénarios indique de déconnecter un du réseau ou d'arrêter le serveur A. Effectuer des modifications à B et assurez-vous que B n'a pas été téléchargé les fichiers sur le serveur de provisioning A.
Pour l'automatiser, le moyen simple d'arrêter le serveur A et de faire les actions appropriées.
Étant donné A et B sont également utilisés à d'autres fins par d'autres parties afin que je ne puisse pas non plus débrancher A ou B du réseau ou arrêter le serveur à A.
Donc, je suis impatient de toute solution pour que je puisse simuler le scénario inaccessible (serveur de provisioning). Donc, quand B Enverra une mise à jour à un, il échouera, mais en réel est en cours d'exécution comme d'habitude.
S'il vous plaît suggérer de moi une façon de y parvenir.
J'utilise Perl comme langage de programmation, mais je vais bien si la solution est disponible dans une autre langue.
3 Réponses :
Je l'ai fait avant d'utiliser un itinéraire nul. C'est quelque chose qui est le mieux fait de la coquille avec la commande IP.
# resond with icmp-host-unreachable for *any* outbound packet to 192.168.2.1 iptables -I OUTPUT -d 192.168.2.1 -j REJECT --reject-with=icmp-host-unreachable # delete the same rule (without looking up the rule #) iptables -D OUTPUT -d 192.168.2.1 -j REJECT --reject-with=icmp-host-unreachable
Merci Jim pour votre réponse rapide. Je suis nouveau au domaine de la mise en réseau. Si je ne me trompe pas, je dois exécuter ces modifications sur le côté serveur?
@ user502937 - Nope, vous ajouteriez l'itinéraire sur le client à l'aide de l'adresse IP du serveur. Cela indiquera que le serveur "a disparu", (ou plus techniquement, la route du serveur est partie).
Bravo. Tellement bon peut provenir de tests qui simulent correctement les échecs. Il n'y a rien de tel que de savoir ce que votre code fera lorsque d'autres systèmes échouent et qu'il dirigera correctement le doigt dans cette direction lorsque le moment est venu de ne pas obtenir l'appel téléphonique iraté 0230.
Une autre, une option peut-être plus facile est de modifier la configuration sur B pour avoir une adresse IP Fausse pour un (par exemple 192.0.2.0) lors de l'exécution du test.
J'aimerais pouvoir faire cela. Comme je l'ai mentionné, les A et B sont utilisés par d'autres parties afin que je ne puisse effectuer aucune modification de la configuration existante.
Test :: MockObject :: s'étend - idéal pour modifier de petites parties de modules pour créer des scénarios de test spécifiques. Fonctionne idéal pour des choses que vous ne pouvez pas bien tester car elles affectent les choses en production ou dans des endroits que vous ne contrôlez pas.
#!/usr/bin/perl
use strict;
use warnings;
use Test::MockObject::Extends;
#Fake module that has your remote connect subroutine
use Fake::Module;
my $object = Fake::Module->new();
#replace your obj with a copy that Test::MO:E will let us mess with
$object = Test::MockObject::Extends->new( $object )
#replace your connect function with a temp fake version
$object->mock(
'your_remote_connect_sub' => sub {
#Whatever data that should returned by your connect function if the server is unavailable
return undef;
},
);
#test your sub now
if ( !defined( $object->your_remove_connect_sub() ) ) {
print "Remote server unavailable\n";
}