Sommaire

Feb 11, 2017 - Understanding Bash fork() Bomb ~ :(){ :|:& };:

Understanding Bash fork() Bomb ~ :(){ :|:& };:

Article original de 2007 mis à jour le 2012-09-02

Can you explain the following bash code or bash fork() bomb?

:(){ :|:& };:

The fork bomb is a form of denial-of-service (DoS) attack against a Linux based system. It makes use of the fork operation.

:(){ :|:& };: is nothing but a bash function. This function get executed recursively. It is often used by sys admin to test user process limitations. Linux process limits can be configured via /etc/security/limits.conf and PAM.

Once a successful fork bomb has been activated in a system it may not be possible to resume normal operation without rebooting the system as the only solution to a fork bomb is to destroy all instances of it.

WARNING! These examples may crash your computer if executed.

Understanding :(){ : :& };: fork() bomb code
  • :() – Defined the function called
  • :. This function accepts no arguments.

The syntax for bash function is as follows:

foo(){
    arg1=$1
    arg2=$2
    echo 'Bar..'
    #do_something on $arg argument
}

fork() bomb is defined as follows:

:(){
 :|:&
};:
  • : : – Next it will call itself using programming technique called recursion and pipes the output to another call of the function ‘:’. The worst part is function get called two times to bomb your system.
  • & – Puts the function call in the background so child cannot die at all and start eating system resources.
  • ; – Terminate the function definition
  • : – Call (run) the function aka set the fork() bomb.

Here is more human readable code:

bomb() { 
 bomb | bomb &
}; bomb

Properly configured Linux / UNIX box should not go down when fork() bomb sets off.

Licence

See original post

Feb 11, 2017 - Expérience de Stanford

Préambule

Le contenu de cet article est issus pour la première partie de Wikipedia. La suite de l’article en anglais provient d’un site spécialisé sur cette expérience.

Wikipedia: Expérience de Stanford

L’expérience de Stanford (effet Lucifer) est une étude de psychologie expérimentale menée par Philip Zimbardo en 1971 sur les effets de la situation carcérale. Elle fut réalisée avec des étudiants qui jouaient des rôles de gardiens et de prisonniers. Elle visait à étudier le comportement de personnes ordinaires dans un tel contexte et eut pour effet de montrer que c’était la situation plutôt que la personnalité autoritaire des participants qui était à l’origine de comportements parfois à l’opposé des valeurs professées par les participants avant le début de l’étude. Les 18 sujets avaient été sélectionnés pour leur stabilité et leur maturité, et leurs rôles respectifs de gardiens ou de prisonniers leur avaient été assignés ostensiblement aléatoirement. En d’autres termes, chaque participant savait que l’attribution des rôles n’était que le simple fruit du hasard et non pas de prédispositions psychologiques ou physiques quelconques. Un gardien aurait très bien pu être prisonnier, et vice-versa.

Les prisonniers et les gardes se sont rapidement adaptés aux rôles qu’on leur avait assignés, dépassant les limites de ce qui avait été prévu et conduisant à des situations réellement dangereuses et psychologiquement dommageables. L’une des conclusions de l’étude est qu’un tiers des gardiens fit preuve de comportements sadiques, tandis que de nombreux prisonniers furent traumatisés émotionnellement, deux d’entre eux ayant même dû être retirés de l’expérience avant la fin.

Malgré la dégradation des conditions et la perte de contrôle de l’expérience, une seule personne (Christina Maslach) parmi les cinquante participants directs et indirects de l’étude s’opposa à la poursuite de l’expérience pour des raisons morales. C’est grâce à celle-ci que le professeur Zimbardo prit conscience de la situation et fit arrêter l’expérience au bout de six jours, au lieu des deux semaines initialement prévues.

Les problèmes éthiques soulevés par cette expérience la rapprochent de l’expérience de Milgram, menée en 1963 à l’Université Yale par Stanley Milgram.

Buts et méthodes

L’étude, financée par l’US Navy et l’US Marine Corps1, visait à comprendre la raison des conflits dans leur système carcéral. Le professeur Zimbardo et son équipe ont voulu tester l’hypothèse selon laquelle les gardiens de prison et les prisonniers adoptaient spontanément par autosélection un comportement menant à une dégradation des conditions de détention. Les participants, recrutés par une annonce dans un journal, étaient payés 15 dollars par jour (ce qui représenterait 84 dollars en 2011) pour participer à une « simulation de prison » d’une durée de deux semaines. Parmi les 70 candidats s’étant présentés, les tests psychologiques et physiques permettent à Zimbardo et son équipe de sélectionner 24 adultes en bonne condition physique et mentale. Ces participants sont tous des étudiants, originaires de tout le continent nord américain, et issus de tous les milieux.

Les candidats furent divisés de manière aléatoire en deux groupes de taille égale, les « prisonniers » et les « gardiens » ; ils sont, de plus, tous parfaitement informés du caractère aléatoire de la répartition des rôles.

La prison se situait dans le sous-sol du bâtiment de psychologie de l’université Stanford. Un assistant de recherche jouait le rôle de directeur et Zimbardo celui de superviseur. Zimbardo imposa des conditions particulières aux participants dans l’espoir d’augmenter la désorientation, la dépersonnalisation et la désindividualisation.

On fournit aux gardes une matraque en bois et un uniforme kaki de type militaire acheté dans un magasin de surplus. Ils avaient également des lunettes de soleil réfléchissantes (comme celles des policiers américains et de certains gardiens de prison) pour éviter tout contact entre les yeux d’un prisonnier et ceux d’un gardien. Contrairement aux prisonniers, les gardes étaient censés travailler en rotation et rentrer chez eux lorsqu’ils n’étaient pas de service, bien que par la suite nombre d’entre eux aient été volontaires pour du travail supplémentaire sans augmentation de salaire.

Les prisonniers devaient porter une sorte de longue blouse, pas de sous-vêtements, et portaient des tongs en caoutchouc, ce qui, selon le professeur Zimbardo, devait les forcer à adopter des postures inhabituelles et à éprouver une sensation d’inconfort pour pousser leur désorientation. Ils étaient appelés par des numéros et non par leur nom. Ces numéros étaient inscrits sur leurs uniformes et ils devaient porter un bas nylon sur le haut de la tête pour simuler un crâne rasé (comme à l’armée). De plus, ils portaient une chaîne aux chevilles, pour leur imposer en permanence le sentiment de leur emprisonnement et leur oppression.

La veille de l’expérience, les gardes assistèrent à une réunion de formation, mais ne reçurent nulle consigne formelle, sinon qu’aucune violence physique n’était autorisée. Ils furent avertis que le bon fonctionnement de la prison était de leur responsabilité, et qu’ils devaient la gérer de la manière qui leur conviendrait.

Zimbardo fit cette déclaration aux gardes durant la formation :

« Vous pouvez créer chez les prisonniers un sentiment d’ennui, de peur jusqu’à un certain degré, vous pouvez créer une notion d’arbitraire par le fait que leur vie soit totalement contrôlée par nous, par le système, vous, moi, et ils n’auront aucune intimité… Nous allons faire disparaître leur individualité de différentes façons. En général, tout ceci mène à un sentiment d’impuissance. Dans cette situation, nous aurons tout le pouvoir et ils n’en auront aucun. »

— The Stanford Prison Study video, citée dans Haslam & Reicher, 2003.55

Les participants désignés comme prisonniers furent simplement prévenus d’attendre chez eux pour être appelés quand l’expérience commencerait. En fait, ils furent arrêtés pour vol à main armée, sans être prévenus, par la police de Palo Alto qui coopérait à cette partie de l’expérience. Les prisonniers durent passer par une procédure de « fichage » complète, incluant la prise des empreintes digitales, les photographies et la lecture de leurs droits. Ils sont fouillés, menottés puis conduits à la prison factice en véhicules de police, à grand renfort de sirènes. Arrivés à destination, ils sont déshabillés et nettoyés à l’aide de produits anti-poux et parasites, puis on leur indique leur nouvelle « identité ».

Résultats

Le contrôle de l’expérience a rapidement été perdu. Les prisonniers ont subi - et accepté - un traitement humiliant et parfois sadique de la part des gardes, et à la fin beaucoup d’entre eux souffraient d’un sévère dérangement émotionnel.

Après un premier jour plutôt calme, une émeute survint le deuxième jour. Les gardes se portèrent volontaires pour des heures supplémentaires et collaborèrent pour casser la révolte, attaquant les prisonniers avec des extincteurs sans être supervisés par l’équipe de recherche. Après cela, les gardes essayèrent de diviser les prisonniers et de les monter les uns contre les autres en créant une « bonne » cellule et une « mauvaise » cellule. Cela devait laisser penser aux prisonniers qu’il y avait des « informateurs » dans leurs rangs. Ces efforts furent largement récompensés, puisqu’il n’y eut plus de grande rébellion. D’après les anciens détenus engagés comme consultants par le professeur Zimbardo, une technique similaire avait été utilisée avec succès dans les vraies prisons aux États-Unis.

Le « comptage de prisonniers », qui avait été mis en place pour que les prisonniers se familiarisent avec leur numéro d’identification, devint une épreuve où durant plusieurs heures les gardes tourmentaient les prisonniers et leur imposaient des punitions physiques, notamment de longues périodes d’exercice physique forcé. Cette prison devint insalubre et inhospitalière ; le droit d’utiliser la salle de bain devint un privilège qui pouvait être - et était souvent - refusé. Certains prisonniers furent forcés de nettoyer les toilettes à mains nues. Les matelas furent retirés de la « mauvaise » cellule et les prisonniers obligés de dormir à même le sol sans aucun vêtement. La privation de nourriture était également souvent utilisée comme punition. De plus, les prisonniers durent endurer une nudité forcée et même des actes d’humiliation sexuelle.

Le professeur Zimbardo lui-même fut victime de son expérience. Le quatrième jour, Zimbardo et les gardes réagirent à une rumeur d’évasion en essayant de déplacer toute l’expérience dans une cellule non utilisée du département de police local, car cela était « plus sûr ». La police refusa, invoquant des problèmes d’assurance, et le professeur Zimbardo se rappelle avoir été énervé et avoir pesté contre le manque de coopération de la police.

L’expérience avançant, de nombreux gardes devinrent progressivement plus sadiques, en particulier la nuit (pensant que les caméras étaient éteintes et que l’équipe de recherche ne pouvait pas les voir). Les cobayes déclarèrent qu’environ un tiers des gardes présentaient de vraies tendances sadiques.

Pour étayer sa théorie selon laquelle les participants avaient intériorisé leur rôle, le professeur Zimbardo avança le fait que lorsqu’on leur proposa une liberté conditionnelle en échange de la confiscation de la totalité de leur paye, la plupart des détenus acceptèrent. Puis, lorsque leur liberté conditionnelle fut néanmoins refusée, aucun ne quitta l’expérience. Le professeur Zimbardo avance qu’il n’y avait aucune raison pour eux de continuer à participer à l’expérience s’ils étaient prêts à renoncer à leur salaire pour la quitter.

Les prisonniers ont commencé à présenter des symptômes de dérangements émotionnels aigus, et l’un d’eux développa un eczéma psychosomatique sur tout le corps quand il apprit que sa demande de liberté conditionnelle était rejetée (le professeur Zimbardo la lui avait refusée, pensant qu’il tentait de sortir de l’expérience en feignant la maladie). Pleurs incontrôlables et pensées désordonnées étaient devenus communs chez les prisonniers. Deux d’entre eux souffraient de troubles si importants qu’ils durent être écartés de l’expérience et remplacés par d’autres cobayes.

L’un des remplaçants, le prisonnier 416, était horrifié par les traitements infligés par les gardes et commença une grève de la faim pour protester. Il fut isolé et enfermé de force dans un placard pendant trois heures. Pendant ce temps, les gardes lui firent tenir les saucisses qu’il avait refusé de manger. Les autres prisonniers le considéraient comme un agitateur. Pour exploiter ce sentiment, les gardes offrirent un choix aux prisonniers : s’ils n’abandonnaient pas leur couverture, le prisonnier 416 serait laissé en isolement toute la nuit. Les prisonniers choisirent de garder leur couverture. Plus tard, le professeur Zimbardo intervint et replaça le prisonnier 416 dans sa cellule.

Le professeur Zimbardo décida de mettre fin à l’expérience plus tôt lorsque Christina Maslach, une ancienne étudiante diplômée qu’il fréquentait à l’époque (et qui devint plus tard sa femme) s’insurgea contre les conditions épouvantables de la « prison » après qu’elle y eut pénétré pour interviewer les prisonniers. Le professeur Zimbardo nota qu’elle fut la seule, parmi la cinquantaine d’intervenants entrés dans la « prison », les amis et membres de la famille autorisés à visiter les sujets, les psychologues professionnels, les étudiants de second cycle en psychologie, le prêtre et le protecteur du citoyen, à mettre la moralité de l’expérience en question. Après seulement six jours sur les deux semaines prévues, l’expérience fut interrompue.

Conclusions

L’expérience de Stanford s’est terminée le 20 août 1971. Le résultat de l’expérience a été utilisé comme argument pour démontrer l’impressionnabilité et l’obéissance des gens en présence d’une idéologie légitime et d’un support institutionnel et social.

En psychologie, les résultats de l’expérience sont censés étayer la thèse d’un comportement en fonction des situations et non des prédispositions (notamment génétiques) des individus. En d’autres termes, il semble que la situation provoque le comportement des participants plus que quoi que ce soit d’inhérent à leur personnalité individuelle. Que le rôle qu’on leur attribue les dépasse, conditionnant leur comportement. En ce sens, les résultats de l’expérience corroborent ceux de la célèbre expérience de Milgram, dans laquelle des gens ordinaires administraient, sous l’ordre d’un professeur, ce qui leur était présenté comme des chocs électriques dangereux à un complice des expérimentateurs.

Peu après que l’étude a été terminée, de sanglantes révoltes éclatèrent à la fois dans la prison d’État de San Quentin et d’Attica (émeutes de la prison d’Attica), et Zimbardo présenta ses résultats à la commission américaine sur la justice.

Critiques

À ce jour, les explications fournies par Zimbardo quant à l’origine du comportement des sujets ne font pas totalement l’objet d’un consensus, et plusieurs critiques se sont exprimées quant à la méthodologie utilisée.

  • Critique de Fromm

L’expérience a été largement décriée comme étant contraire à l’éthique et fondée sur une méthodologie douteuse. Des critiques, et notamment celle d’Erich Fromm, ont remis en question la possibilité de généralisation des résultats de l’expérience. Fromm a en particulier écrit sur la manière dont la personnalité d’un individu affecte son comportement lorsqu’il est emprisonné (en utilisant des exemples historiques comme les camps de concentrations nazis). Ses études vont à l’encontre des conclusions de l’expérience qui affirment que c’est la prison elle-même qui contrôle les comportements des individus. Fromm affirme de plus que le niveau de sadisme chez les sujets « normaux » ne pouvait être déterminé avec les méthodes employées.

  • Critique d’Haslam et Reicher

Haslam et Reicher (2003), deux psychologues de l’université d’Exeter et de St Andrews, ont dirigé une reproduction partielle de l’expérience du professeur Zimbardo avec l’aide de la British Broadcasting Corporation, qui a diffusé des scènes de l’étude en tant qu’un programme de télé-réalité appelé « The Experiment ». Leurs résultats et conclusions furent bien différents de ceux du professeur Zimbardo. Même si leur procédure n’était pas exactement celle de Zimbardo, leur étude jeta des doutes supplémentaires sur la généralité de ses conclusions. En particulier, ils remettent en question le fait que les personnes « glissent » sans opposition dans leur rôle et l’idée que la dynamique du mal ne soit en aucune façon banale. Leur recherche montre également l’importance du (ou des) meneur(s) dans l’émergence d’une tyrannie (d’une forme telle que celle exposée par Zimbardo lors de la formation des gardiens dans l’expérience de Stanford).

  • Un observateur impliqué, une neutralité inexistante

Du fait que cette expérience était in vivo, il était impossible d’utiliser les méthodes de contrôle scientifique. Le professeur Zimbardo n’était pas un observateur neutre, puisqu’il était impliqué dans l’expérience en tant que superviseur de la prison. Les conclusions et observations dessinées par les observateurs étaient largement subjectives et anecdotiques, et l’expérience serait difficile à reproduire par d’autres scientifiques.

  • Au sujet de la validité

Qui plus est, l’expérience a été critiquée sur la base de la validité écologique. Beaucoup des conditions imposées par l’expérience étaient arbitraires et ne correspondaient pas aux conditions réelles des prisons de l’époque (notamment le fait que les prisonniers arrivaient les yeux bandés, qu’on les empêchait de porter des sous-vêtements, de regarder par la fenêtre ou d’utiliser leurs noms). Le professeur Zimbardo justifia ces choix par le fait que la prison est une expérience confuse et déshumanisante et qu’il était nécessaire d’établir ces procédures pour que les « prisonniers » soient dans l’état d’esprit correspondant ; cependant, il est difficile de savoir à quel point les effets étaient les mêmes que dans une prison réelle de l’époque, et les méthodes de l’expérience seraient difficiles à reproduire fidèlement pour que d’autres puissent les tester. De plus, l’échantillon de participants était très réduit, puisqu’ils ne furent qu’au nombre de 24, et ce pour une durée très limitée.

Certaines des critiques formulées avançaient que les participants avaient aligné leur comportement sur ce qu’on attendait d’eux, ou l’ont modelé à partir de stéréotypes qu’ils avaient précédemment sur le comportement de gardiens ou de prisonniers. Autrement dit, les participants étaient simplement engagés dans un jeu de rôles. Le professeur Zimbardo répliqua que même s’il s’agissait d’un jeu de rôles au départ, les participants ont intériorisé leur rôle au fur et à mesure que l’expérience avançait.

Certains déclarèrent que l’étude était trop déterministe : on rapporta des différences significatives de cruauté parmi les gardiens, dont le pire fut surnommé « John Wayne » (il allégua avoir entamé l’escalade d’évènements entre les gardiens et les prisonniers après avoir commencé à jouer le rôle d’un personnage de Luke la main froide, et même avoir intensifié ses actions par la suite du fait qu’on le surnommait John Wayne alors qu’il imitait l’acteur Strother Martin dans le rôle du personnage sadique du Capitaine). Cependant, les autres gardiens étaient plus gentils et rendaient des services aux prisonniers. Le professeur Zimbardo n’essaya pas de trouver une explication à ces différences de comportement.

Stanford Prison Experiment

THE STORY: AN OVERVIEW OF THE EXPERIMENT

1. On a quiet Sunday morning in August, a Palo Alto, California, police car swept through the town picking up college students as part of a mass arrest for violation of Penal Codes 211, Armed Robbery, and Burglary, a 459 PC. The suspect was picked up at his home, charged, warned of his legal rights, spread-eagled against the police car, searched, and handcuffed – often as surprised and curious neighbors looked on.

The suspect was then put in the rear of the police car and carried off to the police station, the sirens wailing.

2. The car arrived at the station, the suspect was brought inside, formally booked, again warned of his Miranda rights, finger printed, and a complete identification was made. The suspect was then taken to a holding cell where he was left blindfolded to ponder his fate and wonder what he had done to get himself into this mess.

SETTING UP

VOLUNTEERS

What suspects had done was to answer a local newspaper ad calling for volunteers in a study of the psychological effects of prison life. We wanted to see what the psychological effects were of becoming a prisoner or prison guard. To do this, we decided to set up a simulated prison and then carefully note the effects of this institution on the behavior of all those within its walls.

More than 70 applicants answered our ad and were given diagnostic interviews and personality tests to eliminate candidates with psychological problems, medical disabilities, or a history of crime or drug abuse. Ultimately, we were left with a sample of 24 college students from the U.S. and Canada who happened to be in the Stanford area and wanted to earn $15/day by participating in a study. On all dimensions that we were able to test or observe, they reacted normally.

Our study of prison life began, then, with an average group of healthy, intelligent, middle-class males. These boys were arbitrarily divided into two groups by a flip of the coin. Half were randomly assigned to be guards, the other to be prisoners. It is important to remember that at the beginning of our experiment there were no differences between boys assigned to be a prisoner and boys assigned to be a guard.

CONSTRUCTING THE EXPERIMENT

1. To help us closely simulate a prison environment, we called upon the services of experienced consultants. Foremost among them was a former prisoner who had served nearly seventeen years behind bars. This consultant made us aware of what it was like to be a prisoner. He also introduced us to a number of other ex-convicts and correctional personnel during an earlier Stanford summer school class we co-taught on “The Psychology of Imprisonment.”

Our prison was constructed by boarding up each end of a corridor in the basement of Stanford’s Psychology Department building. That corridor was “The Yard” and was the only outside place where prisoners were allowed to walk, eat, or exercise, except to go to the toilet down the hallway (which prisoners did blindfolded so as not to know the way out of the prison).

To create prison cells, we took the doors off some laboratory rooms and replaced them with specially made doors with steel bars and cell numbers.

2. At one end of the hall was a small opening through which we could videotape and record the events that occurred. On the side of the corridor opposite the cells was a small closet which became “The Hole,” or solitary confinement. It was dark and very confining, about two feet wide and two feet deep, but tall enough that a “bad prisoner” could stand up.

An intercom system allowed us to secretly bug the cells to monitor what the prisoners discussed, and also to make public announcements to the prisoners. There were no windows or clocks to judge the passage of time, which later resulted in some time-distorting experiences. With these features in place, our jail was ready to receive its first prisoners, who were waiting in the detention cells of the Palo Alto Police Department.

ARRIVAL

  • A STATE OF MILD SHOCK

Blindfolded and in a state of mild shock over their surprise arrest by the city police, our prisoners were put into a car and driven to the “Stanford County Jail” for further processing. The prisoners were then brought into our jail one at a time and greeted by the warden, who conveyed the seriousness of their offense and their new status as prisoners.

  • HUMILIATION

Each prisoner was systematically searched and stripped naked. He was then deloused with a spray, to convey our belief that he may have germs or lice – as can be seen in this series of photos.

A degradation procedure was designed in part to humiliate prisoners and in part to be sure they weren’t bringing in any germs to contaminate our jail. This procedure was similar to the scenes captured by Danny Lyons in these Texas prison photos.

The prisoner was then issued a uniform. The main part of this uniform was a dress, or smock, which each prisoner wore at all times with no underclothes. On the smock, in front and in back, was his prison ID number. On each prisoner’s right ankle was a heavy chain, bolted on and worn at all times. Rubber sandals were the footwear, and each prisoner covered his hair with a stocking cap made from a woman’s nylon stocking.

It should be clear that we were trying to create a functional simulation of a prison – not a literal prison. Real male prisoners don’t wear dresses, but real male prisoners do feel humiliated and do feel emasculated. Our goal was to produce similar effects quickly by putting men in a dress without any underclothes. Indeed, as soon as some of our prisoners were put in these uniforms they began to walk and to sit differently, and to hold themselves differently – more like a woman than like a man.

The chain on their foot, which also is uncommon in most prisons, was used in order to remind prisoners of the oppressiveness of their environment. Even when prisoners were asleep, they could not escape the atmosphere of oppression. When a prisoner turned over, the chain would hit his other foot, waking him up and reminding him that he was still in prison, unable to escape even in his dreams.

The use of ID numbers was a way to make prisoners feel anonymous. Each prisoner had to be called only by his ID number and could only refer to himself and the other prisoners by number.

The stocking cap on his head was a substitute for having the prisoner’s hair shaved off. The process of having one’s head shaved, which takes place in most prisons as well as in the military, is designed in part to minimize each person’s individuality, since some people express their individuality through hair style or length. It is also a way of getting people to begin complying with the arbitrary, coercive rules of the institution. The dramatic change in appearance of having one’s head shaved can be seen on this page.

GUARDS

  • ENFORCING LAW

The guards were given no specific training on how to be guards. Instead they were free, within limits, to do whatever they thought was necessary to maintain law and order in the prison and to command the respect of the prisoners. The guards made up their own set of rules, which they then carried into effect under the supervision of Warden David Jaffe, an undergraduate from Stanford University. They were warned, however, of the potential seriousness of their mission and of the possible dangers in the situation they were about to enter, as, of course, are real guards who voluntarily take such a dangerous job.

As with real prisoners, our prisoners expected some harassment, to have their privacy and some of their other civil rights violated while they were in prison, and to get a minimally adequate diet – all part of their informed consent agreement when they volunteered.

This is what one of our guards looked like. All guards were dressed in identical uniforms of khaki, and they carried a whistle around their neck and a billy club borrowed from the police. Guards also wore special sun-glasses, an idea I borrowed from the movie Cool Hand Luke. Mirror sunglasses prevented anyone from seeing their eyes or reading their emotions, and thus helped to further promote their anonymity. We were, of course, studying not only the prisoners but also the guards, who found themselves in a new power-laden role.

We began with nine guards and nine prisoners in our jail. Three guards worked each of three eight-hour shifts, while three prisoners occupied each of the three barren cells around the clock. The remaining guards and prisoners from our sample of 24 were on call in case they were needed. The cells were so small that there was room for only three cots on which the prisoners slept or sat, with room for little else.

  • ASSERTING AUTHORITY

At 2:30 A.M. the prisoners were rudely awakened from sleep by blasting whistles for the first of many “counts”. The counts served the purpose of familiarizing the prisoners with their numbers (counts took place several times each shift and often at night). But more importantly, these events provided a regular occasion for the guards to exercise control over the prisoners. At first, the prisoners were not completely into their roles and did not take the counts too seriously. They were still trying to assert their independence. The guards, too, were feeling out their new roles and were not yet sure how to assert authority over their prisoners. This was the beginning of a series of direct confrontations between the guards and prisoners.

Push-ups were a common form of physical punishment imposed by the guards to punish infractions of the rules or displays of improper attitudes toward the guards or institution. When we saw the guards demand push-ups from the prisoners, we initially thought this was an inappropriate kind of punishment for a prison – a rather juvenile and minimal form of punishment. However, we later learned that push-ups were often used as a form of punishment in Nazi concentration camps, as can be seen in this drawing by a former concentration camp inmate, Alfred Kantor. It’s noteworthy that one of our guards also stepped on the prisoners’ backs while they did push-ups, or made other prisoners sit or step on the backs of fellow prisoners doing their push-ups.

REBELLION

  • ASSERTING INDEPENDENCE

Because the first day passed without incident, we were surprised and totally unprepared for the rebellion which broke out on the morning of the second day. The prisoners removed their stocking caps, ripped off their numbers, and barricaded themselves inside the cells by putting their beds against the door. And now the problem was, what were we going to do about this rebellion? The guards were very much angered and frustrated because the prisoners also began to taunt and curse them. When the morning shift of guards came on, they became upset at the night shift who, they felt, must have been too lenient. The guards had to handle the rebellion themselves, and what they did was fascinating for the staff to behold.

At first they insisted that reinforcements be called in. The three guards who were waiting on stand-by call at home came in and the night shift of guards voluntarily remained on duty to bolster the morning shift. The guards met and decided to treat force with force.

They got a fire extinguisher which shot a stream of skin-chilling carbon dioxide, and they forced the prisoners away from the doors. (The fire extinguishers were present in compliance with the requirement by the Stanford Human Subjects Research Panel, which was concerned about potential fire threats).

The guards broke into each cell, stripped the prisoners naked, took the beds out, forced the ringleaders of the prisoner rebellion into solitary confinement, and generally began to harass and intimidate the prisoners.

  • SPECIAL PRIVILEGES

The rebellion had been temporarily crushed, but now a new problem faced the guards. Sure, nine guards with clubs could put down a rebellion by nine prisoners, but you couldn’t have nine guards on duty at all times. It’s obvious that our prison budget could not support such a ratio of staff to inmates. So what were they going to do? One of the guards came up with a solution. “Let’s use psychological tactics instead of physical ones.” Psychological tactics amounted to setting up a privilege cell.

One of the three cells was designated as a “privilege cell.” The three prisoners least involved in the rebellion were given special privileges. They got their uniforms back, got their beds back, and were allowed to wash and brush their teeth. The others were not. Privileged prisoners also got to eat special food in the presence of the other prisoners who had temporarily lost the privilege of eating. The effect was to break the solidarity among prisoners.

After half a day of this treatment, the guards then took some of these “good” prisoners and put them into the “bad” cells, and took some of the “bad” prisoners and put them into the “good” cell, thoroughly confusing all the prisoners. Some of the prisoners who were the ringleaders now thought that the prisoners from the privileged cell must be informers, and suddenly, the prisoners became distrustful of each other. Our ex-convict consultants later informed us that a similar tactic is used by real guards in real prisons to break prisoner alliances. For example, racism is used to pit Blacks, Chicanos, and Anglos against each other. In fact, in a real prison the greatest threat to any prisoner’s life comes from fellow prisoners. By dividing and conquering in this way, guards promote aggression among inmates, thereby deflecting it from themselves.

The prisoners’ rebellion also played an important role in producing greater solidarity among the guards. Now, suddenly, it was no longer just an experiment, no longer a simple simulation. Instead, the guards saw the prisoners as troublemakers who were out to get them, who might really cause them some harm. In response to this threat, the guards began stepping up their control, surveillance, and aggression.

Every aspect of the prisoners’ behavior fell under the total and arbitrary control of the guards. Even going to the toilet became a privilege which a guard could grant or deny at his whim. Indeed, after the nightly 10:00 P.M. lights out “lock-up,” prisoners were often forced to urinate or defecate in a bucket that was left in their cell. On occasion the guards would not allow prisoners to empty these buckets, and soon the prison began to smell of urine and feces – further adding to the degrading quality of the environment.

The guards were especially tough on the ringleader of the rebellion, Prisoner #5401. He was a heavy smoker, and they controlled him by regulating his opportunity to smoke. We later learned, while censoring the prisoners’ mail, that he was a self-styled radical activist. He had volunteered in order to “expose” our study, which he mistakenly thought was an establishment tool to find ways to control student radicals. In fact, he had planned to sell the story to an underground newspaper when the experiment was over! However, even he fell so completely into the role of prisoner that he was proud to be elected leader of the Stanford County Jail Grievance Committee, as revealed in a letter to his girlfriend.

GRIEVANCES

Less than 36 hours into the experiment, Prisoner #8612 began suffering from acute emotional disturbance, disorganized thinking, uncontrollable crying, and rage. In spite of all of this, we had already come to think so much like prison authorities that we thought he was trying to “con” us – to fool us into releasing him.

When our primary prison consultant interviewed Prisoner #8612, the consultant chided him for being so weak, and told him what kind of abuse he could expect from the guards and the prisoners if he were in San Quentin Prison. P#8612 was then given the offer of becoming an informant in exchange for no further guard harassment. He was told to think it over.

During the next count, Prisoner #8612 told other prisoners, “You can’t leave. You can’t quit.” That sent a chilling message and heightened their sense of really being imprisoned. P#8612 then began to act “crazy,” to scream, to curse, to go into a rage that seemed out of control. It took quite a while before we became convinced that he was really suffering and that we had to release him.

PARENTS AND FRIENDS

The next day, we held a visiting hour for parents and friends. We were worried that when the parents saw the state of our jail, they might insist on taking their sons home. To counter this, we manipulated both the situation and the visitors by making the prison environment seem pleasant and benign. We washed, shaved, and groomed the prisoners, had them clean and polish their cells, fed them a big dinner, played music on the intercom, and even had an attractive former Stanford cheerleader, Susie Phillips, greet the visitors at our registration desk.

When the dozen or so visitors came, full of good humor at what seemed to be a novel, fun experience, we systematically brought their behavior under situational control. They had to register, were made to wait half an hour, were told that only two visitors could see any one prisoner, were limited to only ten minutes of visiting time, and had to be under the surveillance of a guard during the visit. Before any parents could enter the visiting area, they also had to discuss their son’s case with the Warden. Of course, parents complained about these arbitrary rules, but remarkably, they complied with them. And so they, too, became bit players in our prison drama, being good middle-class adults.

Some of the parents got upset when they saw how fatigued and distressed their son was. But their reaction was to work within the system to appeal privately to the Superintendent to make conditions better for their boy. When one mother told me she had never seen her son looking so bad, I responded by shifting the blame from the situation to her son. “What’s the matter with your boy? Doesn’t he sleep well?” Then I asked the father, “Don’t you think your boy can handle this?”

He bristled, “Of course he can – he’s a real tough kid, a leader.” Turning to the mother, he said, “Come on Honey, we’ve wasted enough time already.” And to me, “See you again at the next visiting time.”

ESCAPE

  • A MASS ESCAPE PLOT

The next major event we had to contend with was a rumored mass escape plot. One of the guards overheard the prisoners talking about an escape that would take place immediately after visiting hours. The rumor went as follows: Prisoner #8612, whom we had released the night before, was going to round up a bunch of his friends and break in to free the prisoners.

How do you think we reacted to this rumor? Do you think we recorded the pattern of rumor transmission and prepared to observe the impending escape? That was what we should have done, of course, if we were acting like experimental social psychologists. Instead, we reacted with concern over the security of our prison. What we did was to hold a strategy session with the Warden, the Superintendent, and one of the chief lieutenants, Craig Haney, to plan how to foil the escape.

After our meeting, we decided to put an informant (an experimental confederate) in the cell that #8612 had occupied. The job of our informant would be to give us information about the escape plot. Then I went back to the Palo Alto Police Department and asked the sergeant if we could have our prisoners transferred to their old jail.

My request was turned down because the Police Department would not be covered by insurance if we moved our prisoners into their jail. I left angry and disgusted at this lack of cooperation between our correctional facilities (I was now totally into my role).

Then we formulated a second plan. The plan was to dismantle our jail after the visitors left, call in more guards, chain the prisoners together, put bags over their heads, and transport them to a fifth floor storage room until after the anticipated break in. When the conspirators came, I would be sitting there alone. I would tell them that the experiment was over and we had sent all of their friends home, that there was nothing left to liberate. After they left, we’d bring our prisoners back and redouble the security of our prison. We even thought of luring #8612 back on some pretext and then imprisoning him again because he was released on false pretenses.

  • A VISIT

I was sitting there all alone, waiting anxiously for the intruders to break in, when who should happen along but a colleague and former Yale graduate student roommate, Gordon Bower. Gordon had heard we were doing an experiment, and he came to see what was going on. I briefly described what we were up to, and Gordon asked me a very simple question: “Say, what’s the independent variable in this study?”

To my surprise, I got really angry at him. Here I had a prison break on my hands. The security of my men and the stability of my prison was at stake, and now, I had to deal with this bleeding-heart, liberal, academic, effete dingdong who was concerned about the independent variable! It wasn’t until much later that I realized how far into my prison role I was at that point – that I was thinking like a prison superintendent rather than a research psychologist.

  • PAYING THEM BACK

The rumor of the prison break turned out to be just a rumor. It never materialized. Imagine our reaction! We had spent an entire day planning to foil the escape, we begged the police department for help, moved our prisoners, dismantled most of the prison – we didn’t even collect any data that day. How did we react to this mess? With considerable frustration and feelings of dissonance over the effort we had put in to no avail. Someone was going to pay for this.

The guards again escalated very noticeably their level of harassment, increasing the humiliation they made the prisoners suffer, forcing them to do menial, repetitive work such as cleaning out toilet bowls with their bare hands. The guards had prisoners do push-ups, jumping jacks, whatever the guards could think up, and they increased the length of the counts to several hours each.

CONCLUSION

  • A KAFKAESQUE ELEMENT

At this point in the study, I invited a Catholic priest who had been a prison chaplain to evaluate how realistic our prison situation was, and the result was truly Kafkaesque. The chaplain interviewed each prisoner individually, and I watched in amazement as half the prisoners introduced themselves by number rather than name. After some small talk, he popped the key question: “Son, what are you doing to get out of here?” When the prisoners responded with puzzlement, he explained that the only way to get out of prison was with the help of a lawyer. He then volunteered to contact their parents to get legal aid if they wanted him to, and some of the prisoners accepted his offer.

The priest’s visit further blurred the line between role-playing and reality. In daily life this man was a real priest, but he had learned to play a stereotyped, programmed role so well – talking in a certain way, folding his hands in a prescribed manner – that he seemed more like a movie version of a priest than a real priest, thereby adding to the uncertainty we were all feeling about where our roles ended and our personal identities began.

  • #819

The only prisoner who did not want to speak to the priest was Prisoner #819, who was feeling sick, had refused to eat, and wanted to see a doctor rather than a priest. Eventually he was persuaded to come out of his cell and talk to the priest and superintendent so we could see what kind of a doctor he needed. While talking to us, he broke down and began to cry hysterically, just as had the other two boys we released earlier. I took the chain off his foot, the cap off his head, and told him to go and rest in a room that was adjacent to the prison yard. I said that I would get him some food and then take him to see a doctor.

While I was doing this, one of the guards lined up the other prisoners and had them chant aloud: “Prisoner #819 is a bad prisoner. Because of what Prisoner #819 did, my cell is a mess, Mr. Correctional Officer.” They shouted this statement in unison a dozen times.

As soon as I realized that #819 could hear the chanting, I raced back to the room where I had left him, and what I found was a boy sobbing uncontrollably while in the background his fellow prisoners were yelling that he was a bad prisoner. No longer was the chanting disorganized and full of fun, as it had been on the first day. Now it was marked by utter confomity and compliance, as if a single voice was saying, “#819 is bad.”

I suggested we leave, but he refused. Through his tears, he said he could not leave because the others had labeled him a bad prisoner. Even though he was feeling sick, he wanted to go back and prove he was not a bad prisoner.

At that point I said, “Listen, you are not #819. You are [his name], and my name is Dr. Zimbardo. I am a psychologist, not a prison superintendent, and this is not a real prison. This is just an experiment, and those are students, not prisoners, just like you. Let’s go.”

He stopped crying suddenly, looked up at me like a small child awakened from a nightmare, and replied, “Okay, let’s go.”

  • PAROLE BOARD

The next day, all prisoners who thought they had grounds for being paroled were chained together and individually brought before the Parole Board. The Board was composed mainly of people who were strangers to the prisoners (departmental secretaries and graduate students) and was headed by our top prison consultant.

Several remarkable things occurred during these parole hearings. First, when we asked prisoners whether they would forfeit the money they had earned up to that time if we were to parole them, most said yes. Then, when we ended the hearings by telling prisoners to go back to their cells while we considered their requests, every prisoner obeyed, even though they could have obtained the same result by simply quitting the experiment. Why did they obey? Because they felt powerless to resist Their sense of reality had shifted, and they no longer perceived their imprisonment as an experiment. In the psychological prison we had created, only the correctional staff had the power to grant paroles.

During the parole hearings we also witnessed an unexpected metamorphosis of our prison consultant as he adopted the role of head of the Parole Board. He literally became the most hated authoritarian official imaginable, so much so that when it was over he felt sick at who he had become – his own tormentor who had previously rejected his annual parole requests for 16 years when he was a prisoner.

  • TYPES OF GUARDS

By the fifth day, a new relationship had emerged between prisoners and guards. The guards now fell into their job more easily – a job which at times was boring and at times was interesting.

There were three types of guards. First, there were tough but fair guards who followed prison rules. Second, there were “good guys” who did little favors for the prisoners and never punished them. And finally, about a third of the guards were hostile, arbitrary, and inventive in their forms of prisoner humiliation. These guards appeared to thoroughly enjoy the power they wielded, yet none of our preliminary personality tests were able to predict this behavior. The only link between personality and prison behavior was a finding that prisoners with a high degree of authoritarianism endured our authoritarian prison environment longer than did other prisoners.

  • JOHN WAYNE

The prisoners even nicknamed the most macho and brutal guard in our study “John Wayne.” Later, we learned that the most notorious guard in a Nazi prison near Buchenwald was named “Tom Mix” – the John Wayne of an earlier generation – because of his “Wild West” cowboy macho image in abusing camp inmates.

Where had our “John Wayne” learned to become such a guard? How could he and others move so readily into that role? How could intelligent, mentally healthy, “ordinary” men become perpetrators of evil so quickly? These were questions we were forced to ask.

  • PRISONERS’ COPING STYLES

Prisoners coped with their feelings of frustration and powerlessness in a variety of ways. At first, some prisoners rebelled or fought with the guards. Four prisoners reacted by breaking down emotionally as a way to escape the situation. One prisoner developed a psychosomatic rash over his entire body when he learned that his parole request had been turned down. Others tried to cope by being good prisoners, doing everything the guards wanted them to do. One of them was even nicknamed “Sarge,” because he was so military-like in executing all commands.

By the end of the study, the prisoners were disintegrated, both as a group and as individuals. There was no longer any group unity; just a bunch of isolated individuals hanging on, much like prisoners of war or hospitalized mental patients. The guards had won total control of the prison, and they commanded the blind obedience of each prisoner.

  • ONE FINAL ACT OF REBELLION

We did see one final act of rebellion. Prisoner #416 was newly admitted as one of our stand-by prisoners. Unlike the other prisoners, who had experienced a gradual escalation of harassment, this prisoner’s horror was full-blown when he arrived. The “old timer” prisoners told him that quitting was impossible, that it was a real prison.

Prisoner #416 coped by going on a hunger strike to force his release. After several unsuccessful attempts to get #416 to eat, the guards threw him into solitary confinement for three hours, even though their own rules stated that one hour was the limit. Still, #416 refused.

At this point #416 should have been a hero to the other prisoners. But instead, the others saw him as a troublemaker. The head guard then exploited this feeling by giving prisoners a choice. They could have #416 come out of solitary if they were willing to give up their blanket, or they could leave #416 in solitary all night.

What do you think they chose? Most elected to keep their blanket and let their fellow prisoner suffer in solitary all night. (We intervened later and returned #416 to his cell.)

  • AN END TO THE EXPERIMENT

On the fifth night, some visiting parents asked me to contact a lawyer in order to get their son out of prison. They said a Catholic priest had called to tell them they should get a lawyer or public defender if they wanted to bail their son out! I called the lawyer as requested, and he came the next day to interview the prisoners with a standard set of legal questions, even though he, too, knew it was just an experiment.

At this point it became clear that we had to end the study. We had created an overwhelmingly powerful situation – a situation in which prisoners were withdrawing and behaving in pathological ways, and in which some of the guards were behaving sadistically. Even the “good” guards felt helpless to intervene, and none of the guards quit while the study was in progress. Indeed, it should be noted that no guard ever came late for his shift, called in sick, left early, or demanded extra pay for overtime work.

I ended the study prematurely for two reasons. First, we had learned through videotapes that the guards were escalating their abuse of prisoners in the middle of the night when they thought no researchers were watching and the experiment was “off.” Their boredom had driven them to ever more pornographic and degrading abuse of the prisoners.

Second, Christina Maslach, a recent Stanford Ph.D. brought in to conduct interviews with the guards and prisoners, strongly objected when she saw our prisoners being marched on a toilet run, bags over their heads, legs chained together, hands on each other’s shoulders. Filled with outrage, she said, “It’s terrible what you are doing to these boys!” Out of 50 or more outsiders who had seen our prison, she was the only one who ever questioned its morality. Once she countered the power of the situation, however, it became clear that the study should be ended.

And so, after only six days, our planned two-week prison simulation was called off.

On the last day, we held a series of encounter sessions, first with all the guards, then with all the prisoners (including those who had been released earlier), and finally with the guards, prisoners, and staff together. We did this in order to get everyone’s feelings out in the open, to recount what we had observed in each other and ourselves, and to share our experiences, which to each of us had been quite profound.

We also tried to make this a time for moral reeducation by discussing the conflicts posed by this simulation and our behavior. For example, we reviewed the moral alternatives that had been available to us, so that we would be better equipped to behave morally in future real-life situations, avoiding or opposing situations that might transform ordinary individuals into willing perpetrators or victims of evil.

Two months after the study, here is the reaction of prisoner #416, our would-be hero who was placed in solitary confinement for several hours:

“I began to feel that I was losing my identity, that the person that I called Clay, the person who put me in this place, the person who volunteered to go into this prison – because it was a prison to me; it still is a prison to me. I don’t regard it as an experiment or a simulation because it was a prison run by psychologists instead of run by the state. I began to feel that that identity, the person that I was that had decided to go to prison was distant from me – was remote until finally I wasn’t that, I was 416. I was really my number.”

Compare his reaction to that of the following prisoner who wrote to me from an Ohio penitentiary after being in solitary confinement for an inhumane length of time:

“I was recently released from solitary confinement after being held therein for thirty-seven months. The silence system was imposed upon me and if I even whispered to the man in the next cell resulted in being beaten by guards, sprayed with chemical mace, black jacked, stomped, and thrown into a strip cell naked to sleep on a concrete floor without bedding, covering, wash basin, or even a toilet…. I know that thieves must be punished, and I don’t justify stealing even though I am a thief myself. But now I don’t think I will be a thief when I am released. No, I am not rehabilitated either. It is just that I no longer think of becoming wealthy or stealing. I now only think of killing – killing those who have beaten me and treated me as if I were a dog. I hope and pray for the sake of my own soul and future life of freedom that I am able to overcome the bitterness and hatred which eats daily at my soul. But I know to overcome it will not be easy.”

  • TERMINATED ON AUGUST 20, 1971

Our study was terminated on August 20, 1971. The next day, there was an alleged escape attempt at San Quentin. Prisoners in the Maximum Adjustment Center were released from their cells by Soledad brother George Jackson, who had smuggled a gun into the prison. Several guards and some informant prisoners were tortured and murdered during the attempt, but the escape was prevented after the leader was allegedly gunned down while trying to scale the 30-foot high prison walls.

Less than one month later, prisons made more news when a riot erupted at Attica Prison in New York. After weeks of negotiations with prisoners who held guards hostage while demanding basic human rights, New York Governor Nelson Rockefeller ordered the National Guard to take back the prison by full force. A great many guards and prisoners were killed and injured by that ill-advised decision.

One of the major demands of the prisoners at Attica was that they be treated like human beings. After observing our simulated prison for only six days, we could understand how prisons dehumanize people, turning them into objects and instilling in them feelings of hopelessness. And as for guards, we realized how ordinary people could be readily transformed from the good Dr. Jekyll to the evil Mr. Hyde.

The question now is how to change our institutions so that they promote human values rather than destroy them. Sadly, in the decades since this experiment took place, prison conditions and correctional policies in the United States have become even more punitive and destructive. The worsening of conditions has been a result of the politicization of corrections, with politicians vying for who is toughest on crime, along with the racialization of arrests and sentencing, with African-Americans and Hispanics overrepresented. The media has also contributed to the problem by generating heightened fear of violent crimes even as statistics show that violent crimes have decreased.

There are more Americans in prisons than ever before. According to a Justice Department survey, the number of jailed Americans more than doubled during the past decade, with over 2 million people in jail or prison by 2005. To learn more about prisons, the Stanford Prison Experiment, and parallels with recent events such as the abuse of Iraqi prisoners, please consult the bibliography below or visit the Related Links page.

BIBLIOGRAPHY

  • Zimbardo, P. G. (2007). The Lucifer Effect: Understanding how good people turn evil. New York: Random House. [See also LuciferEffect.com]
  • Schwartz, J. (May 6, 2004). Simulated prison in ‘71 showed a fine line between “normal” and “monster.” New York Times, p. A20.
  • Zimbardo, P. G. (2004). A situationist perspective on the psychology of evil: Understanding how good people are transformed into perpetrators (pp. 21-50). In A. G. Miller (Ed.), The social psychology of good and evil. New York: Guilford Press.
  • Zimbardo, P. G., Maslach, C., & Haney, C. (2000). Reflections on the Stanford Prison Experiment: Genesis, transformations, consequences. In T. Blass (Ed.), Obedience to authority: Current Perspectives on the Milgram paradigm (pp. 193-237). Mahwah, NJ: Erlbaum.
  • Haney, C., & Zimbardo, P. G. (1998). The past and future of U.S. prison policy: Twenty-five years after the Stanford Prison Experiment. American Psychologist, 53, 709-727.
  • Zimbardo, P. G., Haney, C., Banks, W. C., & Jaffe, D. (1973, April 8). The mind is a formidable jailer: A Pirandellian prison. The New York Times Magazine, Section 6, 36, ff.
  • Haney, C., Banks, W. C., & Zimbardo, P. G. (1973). Interpersonal dynamics in a simulated prison. International Journal of Criminology and Penology, 1, 69-97.
  • Zimbardo, P. G. (1971). The power and pathology of imprisonment. Congressional Record. (Serial No. 15, October 25, 1971). Hearings before Subcommittee No. 3, of the Committee on the Judiciary, House of Representatives, 92nd Congress, First Session on Corrections, Part II, Prisons, Prison Reform and Prisoners’ Rights: California.Washington, DC: U.S. Government Printing Office.

Licence

Le contenu présenté ici est soumis aux licences d’origine. Il est dupliqué ici afin de conserver une archive.

Feb 11, 2017 - Docker et la tendance de la conteneurisation : a-t-elle vraiment été en production ?

Préambule

Ce texte est une copie pour archive d’un article. Le texte original est disponible chez blog.imirhil.fr.

Le texte a été publié le 2016-10-09

Docker et la tendance de la conteneurisation : a-t-elle vraiment été en production ?

Docker. Une technologie si jeune (2013) et pourtant dorénavant vendue un peu partout comme la technologie miracle qui va résoudre tous les problèmes de déploiement, vous rendre riche et vous ramener l’être aimé.

Et pourtant, en pratique cette technologie me pose pas mal de problèmes et de cas de conscience. Revue de détails.

Objectif : portabilité

Le but initial est un peu dans le prolongement de ce qu’a fait Java : construire une fois, déployer partout (« build once, deploy everywhere »). On ne peut nier que l’idée initiale soit bonne tellement le problème du déploiement est un véritable parcours du combattant en pratique.

Un logiciel est rarement un morceau totalement isolé. Il vient avec son interpréteur, ses bibliothèques, nécessite un moteur de base de données, des fichiers de configuration, un serveur web et tout un tas d’autres choses. Cet écosystème va être à gérer tout au long de la chaîne de fabrication, que ça soit en développement, en phase de validation/qualification, en recette ou encore en production.

Avant Docker, chaque étape nécessitait de remonter l’ensemble de l’environnement, d’y installer le logiciel (parfois à partir des sources via compilation), de le lancer… Et c’était un gros bordel, puisque la moindre déviation entre deux environnements pouvait conduire à des bugs non reproductibles en fonction de l’endroit où l’on lançait le logiciel, d’où l’apparition du trop fameux « Ça marche chez moi ™ ».

Avec Docker, point de tout cela. Les développeurs construisent une image du logiciel qui va contenir tout ce qui lui faut pour fonctionner, depuis l’OS jusqu’au logiciel lui-même en passant par toutes les autres briques. S’ils ont satisfaction de ce qu’ils ont obtenu, ils livreront à l’étape suivante cette image, qui n’aura pas bougé d’un iota et pourra être lancée à l’identique, et ainsi de suite jusqu’à la très attendue mise en production.

Ça c’est la théorie. Maintenant, la pratique :D

Besoins de dev ≠ besoin de la prod

Le premier rempart à l’usage de Docker est que les besoins entre la production et le développement sont assez différents. Un développeur va vouloir accéder facilement aux journaux, si possible en mode debug, alors que la prod préférera les envoyer à un Logstash et en mode info voire warn ou error. Un développeur préférera utiliser directement le serveur d’application léger de son choix comme Jetty, Thin ou Gunicorn, alors que la production configurera un backend Nginx devant ou utilisera des serveurs d’application plus puissant tel que Tomcat ou Passenger. Un développeur préférera sûrement compiler en mode debug pour avoir des retours utilisables en cas de problème alors que la production insistera pour le faire en mode release. La production voudra mettre en place un pare-feu, ou ses outils de supervision de parc, dont le développement n’a même aucune idée de l’existence puisque ça ne fait pas partie de ses compétences ! J’évite même de parler d’intégrer ses outils de développement à un environnement Docker, par exemple lancer son projet Java présent sur son Eclipse local sur le Tomcat présent sur l’image Docker, ça ferait trop mal. Bref, en pratique, c’est compliqué… On peut quand même s’en sortir pour certains morceaux, surtout grâce à certaines fonctionnalités de Docker, mais l’intérêt en devient limité.

Pour les environnements différents, il « suffit » que les devs travaillent hors Docker à l’ancienne, puis une fois parvenus à quelque chose de satisfaisant, s’attaquent à la construction d’une image Docker. Ça implique une espèce de mini-chaîne complète (dev/test/validation/qualification/production) faite uniquement par les développeurs, afin de s’assurer que l’image finale est à peu près conforme à ce qui est attendu (quel logiciel fournir, quelles dépendances disponibles…). Parce que du coup ça n’implique plus que si ça tourne sur leur environnement de dev, ça tourne sur l’environnement Docker. Pas forcément très folichon niveau processus sinon avoir ramené toutes les considérations des autres étapes sur celle de développement.

Pour les besoins propres à la production (pare-feu, monitoring…), Docker permet de créer une image à partir d’une autre. La production repartira donc de l’image fournie par les développeurs pour refaire sa propre image incluant tout le nécessaire. Ça casse aussi l’intérêt de Docker qui garantit que ça tournera en production, étant donné que la production peut elle aussi introduire des bugs. Par exemple l’installation d’un pare-feu va peut-être installer une bibliothèque utilisée par l’application mais dans une version différente. La production devra donc aussi repasser une bonne partie des étapes précédentes (test/validation/qualification) avant la mise en production réelle. Pas folichon non plus.

Dans les deux cas il aurait été plus intelligent que le dev et la prod travaillent ensemble dès le départ (qui a dit Devops ?) pour fournir une image Docker à la QA qui partira en production telle quelle une fois approuvée. Mais alors qu’on utilise Docker ou n’importe quelle autre technologie (virtualisation classique, automatisation d’installation via un outil comme Chef, Puppet, Ansible ou Salt) on aurait obtenu le même résultat.

Quid de la sécurité ?

LE gros point noir selon moi.

Docker repose sur le principe d’immuabilité des images. Une fois une image livrée, on n’y touche plus et au prochain changement nécessaire, on refait une image depuis zéro.

Ça pose un problème assez énorme en termes de sécurité. Le jour où vous avez une faille dans le logiciel livré, on comprend bien qu’on n’échappera de toute façon pas à un correctif, une regénération, un passage intégral de toute la chaîne de qualification et une nouvelle mise en production. Mais si c’est une bibliothèque utilisée par le logiciel, par exemple OpenSSL qui connaît au moins une faille critique de sécurité par jour ?

Dans une infrastructure sans Docker, les gentils administrateurs systèmes se seraient sagement connectés en SSH aux machines impactées, auraient simplement fait un apt update && apt upgrade et basta. Un patch de sécurité n’introduisant pas de changement de fonctionnalités et les développeurs de OpenSSL faisant bien leur travail, ils livrent des versions patchées assurant la rétro-compatibilité avec les versions précédentes. Les admins peuvent donc appliquer le patch assez rapidement sans avoir besoin de consulter les développeurs. Et la faille est rapidement corrigée avec un risque de régression négligeable (qu’on a parfaitement su accepter et maîtriser pendant des décennies, et même Docker ne pourra jamais garantir le 0 bug). En prime, le logiciel final, lui, n’a pas changé de version.

Dans une infrastructure dockerisée, c’est une autre histoire… Les conteneurs devant être immuables, il est interdit aux administrateurs de se connecter aux machines pour les mettre à jour. Un changement de sécurité sur une bibliothèque réclame donc de redérouler l’intégralité de la chaîne : on met à jour la bibliothèque, on construit une nouvelle image Docker (qui change donc de version), on repasse toute la QA, on met en production. La mise en production nécessite un arrêt de l’ancienne image, la migration des données sur la nouvelle image et le redémarrage du système. Bref, vous allez tourner un long moment avec votre image trouée avant d’avoir pu fixer le problème…

Quand on évoque ce problème avec la communauté Docker, ils avancent alors leur recette miracle : l’intégration continue. Certes, si vous réussissez à intégrer l’intégralité de la QA (tests unitaires, tests fonctionnels, tests d’intégration, tests de validation, tests de qualification, tests de recette) dans une suite de tests automatiques, c’est peut-être envisageable de faire une modification dans le code, de cliquer sur un bouton et d’avoir automagiquement la nouvelle version en production. En pratique, on a déjà du mal à atteindre 100% de couverture sur les tests unitaires, et plus on monte dans les étages plus c’est compliqué. Les tests fonctionnels doivent simuler des humains presse-boutons, les tests d’intégration sont un enfer à réaliser vu le nombre de composants en jeu, les tests de qualification sont souvent longs (tests de performance, de tenue de charge…), etc. Sauf à investir un budget colossal en automatisation de tests, l’intégration continue revient finalement à se restreindre à un sous-ensemble des tests (on se limite aux cas principaux et on laisse tomber les cas dégradés par exemple) et donc à potentiellement laisser passer des bugs lorsque les administrateurs pousseront le bouton « Déployer » après une modification rapide pour fixer une faille de sécurité. Seuls les grands comme Google ou Amazon peuvent se permettre l’outillage de détection d’un problème en production (du test A/B par exemple) et donc d’alléger ou de supprimer toutes les phases de test : on déploie plus ou moins à l’arrache, si ça merde, on revient en arrière immédiatement !

Les plus perspicaces d’entre vous auront noté que tout ce qui précède repose sur une hypothèse très forte : on doit être mainteneur de l’image Docker utilisée ! En pratique, beaucoup utilisent des images pré-construites qu’ils assemblent selon leurs besoins. Il existe des dépôts d’images, dont le plus connu est le Hub Docker. Du coup, en cas de faille, il va vous falloir attendre une mise-à-jour. L’unique mainteneur est passé sous un bus ? Vous êtes mal… En termes de sécurité, c’est même encore plus gore dans ce cas, puisque vous n’avez pas beaucoup de moyens de vous assurer que l’image de 600Mo (n’oublions pas que ça intègre un OS complet) que vous allez utiliser n’intègre pas une porte dérobée ou une version obsolète d’une bibliothèque, surtout quand l’image est réalisée avec les pieds et ne permettent aucune vérification a posteriori. Les paquets Debian sont par exemple construits en compilation reproductible et vous pouvez facilement vous assurer que le nginx que vous utilisez est bien le même que celui du paquet Debian officiel alors que sous Docker, je vous souhaite bien du courage ne serait-ce que pour connaître le numéro de version utilisé. Sur chaque image Docker, il faudrait faire une revue assez poussée de ce qui se trouve sur l’image, au moins pour lister les différents composants et bibliothèques intégrés et ainsi connaître les impacts réels sur votre parc d’un correctif de sécurité.

Mono-processus : ma vie, mon œuvre

L’humanité s’est battue pendant des décennies pour mettre en place le multi-processus, puis le multi-thread… Mais ça c’était avant ! Avec Docker, vous ne pouvez lancer qu’un seul et unique processus dans une image. Pas plus. Ça n’a l’air de rien, mais c’est très handicapant en pratique. Vous ne pouvez pas avoir cron à tourner régulièrement par exemple. Donc pas de logrotate. Vous ne pouvez pas avoir de serveur SSH pour vous connecter à distance sur l’image. Pas de serveur de mail non plus, par exemple pour les rapports journaliers de logwatch (de toute façon on n’a pas cron pour les lancer…). Rien. La seule et unique chose que vous allez pouvoir lancer sera donc votre application. Et c’est tout.

Le problème est que comme on l’a vu précédemment, une application se suffit généralement assez peu à elle-même. Elle nécessite par exemple une base de données, un frontal web, de pouvoir envoyer des courriels… Et donc de lancer plusieurs processus !

En méthode quick & dirty, vous pouvez contourner le problème en lançant un bête script bash qui lancera tout en arrière-plan, ou plus malin un gestionnaire de processus comme supervisord ou pups qui se chargera lui-même de lancer tout le reste de ce que vous avez besoin. C’est tout de même assez galère à faire puisque votre distribution adorée vous fournira des scripts de démarrage pour le système d’init habituel (sysv, systemd, upstart…) et non pour supervisord ou pups, il vous faudra donc faire un travail de portage pour chaque composant nécessaire.

La méthode recommandée par Docker pour gérer vos environnements est l’utilisation de Docker Compose. Vous allez créer autant de conteneurs que de composants de votre écosystème (un pour l’application, un pour la base de données, un pour le serveur de courriel…) et les assembler entre-eux pour qu’ils communiquent correctement. Pour certains composants comme la base de données, je trouve ça intéressant de séparer du reste, exactement comme on l’aurait fait dans une infrastructure non virtualisée. Pour d’autres, comme un serveur de courriel dédié pour envoyer 3 courriels au mois, c’est du gaspillage de ressources flagrant. Et pour la majorité, c’est d’une prise de tête sans nom…

Par exemple dans une application Ruby-on-Rails utilisant Sidekiq comme ordonnanceur, on va se retrouver à avoir 4 conteneurs :

  • 1 pour l’application Ruby-on-Rails
  • 1 pour le backend web nginx
  • 1 pour Sidekiq
  • 1 pour le serveur Redis qui sert à la communication entre RoR et Sidekiq

Alors que tout mettre sur la même machine se justifie largement tant qu’on n’a pas une volumétrie délirante (je tiens les 200.000 vues quotidiennes sur Cryptcheck sans soucis avec 1 seul conteneur), on se retrouve avec 4 machines à gérer et à devoir mettre à jour (les 4 utilisent OpenSSL par exemple) et une duplication de l’environnement Ruby (RoR & Sidekiq). On risque aussi de rencontrer des dégradations de performances, puisqu’on passe de communications sur la boucle locale voire des sockets UNIX à une communication TCP/IP externe. Et la sécurité devient tout autant un enfer, avec de la gestion de pare-feu à mettre en œuvre.

Pour gérer autant de conteneurs, vous allez aussi devoir passer à des outils de gestion de déploiement et d’orchestration, comme Kubernetes. Toujours pareil, quand vous vous appelez Google, Wikimedia, SAP ou Ebay, c’est peut-être gérable. Si vous êtes une petite boîte, ça risque d’avoir un surcoût non négligeable et pas forcément rentable.

De la chasse aux méga-octets à la chasse aux bugs non reproductibles

On a vu juste avant que Docker incite à créer plein de conteneurs pour les assembler entre eux. En interne pour la fabrication de ses propres images, Docker se base aussi sur des images pré-construites qu’il empile les unes sur les autres au travers de OverlayFS. Pour l’image Sidekiq, c’est pas moins de 39 couches empilées.

Déjà, ça n’aide pas à la sécurité non plus, puisqu’une faille corrigée sur une couche réclame la reconstruction de toutes les images situées sur les couches supérieures. Ou alors vous corrigez violemment sur votre couche terminale, mais vous dupliquez alors vos bibliothèques (installées par une couche N mais masquées via overlayfs par la couche N+X) et vous avez le travail à faire sur toutes vos images utilisant la couche faillible.

Ensuite, si on utilisait des images standard, on se retrouverait à consommer plusieurs giga-octets pour pas grand-chose. Du coup, la communauté Docker a commencé à faire la chasse aux méga-octets, et s’est prise de passion pour une distribution présentée comme très légère : Alpine Linux.

Cette distribution vient avec un gros piège… Elle est conçue à la base pour aider à débugger des kernel ! Parce que quand vous développez ce genre de logiciel, vous êtes bien content d’avoir une image de 5Mo qui démarre en 2s, vu le nombre de redémarrages que vous allez faire. Et comme vous ne ferez presque rien côté utilisateur, on peut y mettre des trucs très légers comme musl et busybox au lieu des mastodontes que sont la glibc et les coreutils.

Sauf que musl n’est pas compatible avec la glibc disponible un peu partout. Ni au niveau binaire, ce qui signifie que vous devez compiler explicitement vos logiciels avec cette libc et donc maintenir à la fois un livrable -glibc pour les gens hors de Alpine et un -musl pour Alpine. Ni au niveau fonctionnalités, ce qui fait que vous pouvez rencontrer des bugs incompréhensibles et non reproductibles sur d’autres plate-formes plus standard. Ça peut aller jusqu’à l’impossibilité totale de compiler votre logiciel, comme c’est le cas actuellement avec OpenJDK 8 ou Phusion Passenger.

Bref, vous allez vous retrouver à soit utiliser des images du Hub Docker avec une chance non négligeable d’utiliser un conteneur Alpine dans votre chaîne et faire la chasse aux bugs vraiment chiants à comprendre, soit à devoir faire votre propre image personnelle sans Alpine… Le tout en croisant les doigts à chaque construction d’image pour ne pas tomber en plus sur une image contenant une faille de sécurité…

Au final, Docker passe en plus complètement à côté de la plaque en termes de consommation de ressources. À titre d’exemple, la stack précédente RoR/Redis/Sidekiq/Nginx ramène pour 60 overlays Docker et 3.1 Go d’espace disque, quand je m’en tire pour 1.8 Go pour Cryptcheck avec une stack dev/RoR/Redis/Sidekiq/Nginx/Elasticsearch/CryptCheck/données. Un beau gâchis d’espace…

Une tendance qui se propage de plus en plus

Cette tendance du « je package tout dans un seul truc » est devenu à la mode et on la retrouve vraiment partout. Même si la complexité induite par ce type de systèmes peut être problématique, c’est vraiment le problème de la gestion de la sécurité qui est très dangereuse en pratique. On a déjà du mal à maintenir nos parcs plus ou moins à jour avec une infrastructure pas trop complexe, ça risque de devenir un véritable carnage une fois des outils comme Docker (mal) utilisé un peu partout…

Go, langage d’ailleurs utilisé par Docker lui-même, compile vos projets sous forme d’un exécutable statique qui embarque donc toutes vos bibliothèques. Ça a l’avantage de ne pas nécessiter leur installation, mais ça pose tous les problèmes de sécurité vus auparavant avec la recompilation nécessaire de tous vos binaires au moindre changement d’une bibliothèque. Sachant en plus que la gestion des dépendances y est très mauvaise puisque se base par défaut sur les branches master de dépôts GitHub et non sur des tags, c’est une bombe à retardement dans vos systèmes. Par exemple vous êtes actuellement incapable de recompiler d’anciennes versions de pas mal de logiciels puisque des dépendances ont fait des modifications non rétro-compatibles avec les anciennes versions de Go et que les versions des dépendances utilisées à l’époque ne sont mentionnées nulle part. La situation devrait cependant s’améliorer avec l’introduction du vendoring depuis Go 1.5.

Snap, la nouvelle idée à la con le nouveau format de paquets d’Ubuntu/Canonical embarque aussi dans une image statique votre logiciel et toutes ses bibliothèques. La problématique de sécurité devient encore pire puisqu’ici, on parle d’une utilisation en tant qu’environnement de bureau. Par exemple sur mon PC, je me retrouverais avec 60 versions de libssl, utilisée par postfix, openssl, bind9, gstreamer, virtualbox, isync, ntp, postgresql, nmap, tor, mumble, irssi, xca, openssh, apache2, telnet ou encore socat… Le jour où il faudra mettre à jour tout ça, ça va être une belle tranche de rigolade et on n’aura sûrement pas la réactivité qu’a pu avoir le projet Debian sur Heartbleed par exemple, corrigé en quelques heures et disponible tout aussi rapidement sur l’ensemble des dépôts. Quand je leur ai posé la question, ils ont uniquement réfléchi à la mise-à-jour d’un point de vue « binaires » et n’ont même pas pensé à la problématique des migrations de données. Encore une fois, transformer les mainteneurs d’une application en mainteneurs d’un écosystème complet est loin d’être anodin ici, et le travail à abattre fera que la sécurité ne pourra plus être assurée.

Comment fait-on alors ?

Utiliser des conteneurs, ça peut quand même avoir du bon.

Je m’en sers beaucoup en développement pour monter un environnement stable et surtout pouvoir gérer des environnements difficiles à mixer proprement dans un même système (gcc 4.9 & 6.1 par exemple) ou avec des dépendances pouvant entrer en conflit avec celles du système (l’enfer ffmpeg/avidemux/audacity…). Ça permet aussi de revenir rapidement à un état propre et maîtrisé. En phase de développement on a généralement tendance à installer des tonnes de choses à la truelle et à modifier violemment son système pour faciliter le debug ou pour chercher la cause d’un problème. Mais c’est toujours intéressant de recompiler sur une machine vierge pour vérifier qu’on n’a pas oublié un bout. Et enfin ça peut faciliter la reproductibilité d’un bug si l’utilisateur qui le détecte parvient à vous fournir une image démontrant le problème plutôt que de faire face à des « mais ça ne marche pas chez moi ™ ».

Mais par pitié, arrêtez de vouloir mettre en production des blobs galères à gérer, en particulier en termes de sécurité, qui compliquent le moindre audit pour savoir ce qui tourne là-dedans et qui transforment les infrastructures en plat de spaghetti…

Un petit conteneur LXC tout simple, construit à partir de debootstrap générant une image de maximum 200Mo toute mouillée et dans laquelle vous allez installer vos logiciels au mieux avec du apt/dpkg standard et au pire quelques scripts automatisant l’installation (du bon vieux bash over chroot ou du ansible/salt), ça fonctionne simplement et c’est facile à gérer côté sécurité. Et vous découpez vos conteneurs non plus par logiciel comme sous Docker, mais par besoin : 1 conteneur pour toute la stack Discourse, 1 pour votre serveur de courriel entrant, 1 pour votre serveur DNS faisant autorité, etc.

Licence

La licence de publication est Creative Common BY-NC-SA.

Jan 17, 2016 - Architecture Orientée Message, Implémentation

Architecture de services Orientée Messages, Implémentation

Introduction

Ce document présente une réalisation de l’Architecture Orientée Message présentée dans un autre article. Pour mémoire cette architecture est composée de 2 familles d’applications (producteur de messages et consommateur) qui échangent des messages par l’intermédiaire d’un broker. Dans ce modèle, le broker joue le rôle de gestionnaire de message. Il sait comment orienter les messages entre le producteur et le/les destinataires sans que les applications connectées aient besoin de le savoir.

L’outil, le broker de messages sélectionné est RabbitMQ.

ZeroMQ est réputé pour être plus performant mais pas pour son interface de gestion. Cette solution est populaire pour la performance brute ce qui n’est pas le but recherché pour le moment.

Quelques tests menés sur un ordinateur portable montrent que RabbitMQ peut supporter un flux de 20k messages par secondes de manière soutenue (3h) ce qui est largement suffisant pour le cahier des charges.

Pour ceux qui veulent directement le schéma d’implémentation, c’est par là .

Notions de routage de message

Pour une explication globale des concept de routage de message, c’est par ici.

Pour simplifier au maximum, le service assurant le dispatch des messages est composé d’un point d’échange auquel un producteur envoie des messages, ainsi que de files d’attente qui stockent les messages devant être récupérés par des consommateurs. Selon la configuration (type de point d’échange, “binding”) un message peut être remis à 0, 1 ou plusieurs consommateurs.

L’intérêt d’utiliser un outil pour faire cette fonction est multiple :

  • séparer les producteur des consommateurs (= ils n’ont pas besoin de pouvoir communiquer directement ni de manière synchrone. Pas de dépendance logicielle entre le consommateur et le producteur, seulement être d’accord sur le format de message)
  • réaliser l’inversion de contrôle (IoC) permettant de pouvoir lancer les applications dans le sens que l’on souhaite sans s’occuper de l’ordre des traitements (en terme réseau, les applications sont clientes. Le broker est serveur).
  • pas besoin de réinventer la roue de la communication réseau avec les problèmes associés (outil de supervision, ré-émission des messages, sauvegarde sur disque …)

La spécification d’AMQP définie plusieurs façon de router les messages, comme indiqué dans les concepts.

Dans le cas présent un routage basé sur la clef de routage est utilisé.

  • Exemple d’utilisation de la clef de routage

Le routage par motif permet de router un message dans plusieurs files d’attentes.

Dans cet exemple, la clef de routage associée aux messages est composée d’une partie géographique (europe, …) et une autre partie qui indique la nature (news, ….) du message.

Les files d’attentes ont la possibilité de choisir :

  • un type d’information particulier pour une zone spécifique (europe.news),
  • tous les messages d’une zone spécifique (europe.#),
  • un type d’information particulier pour toutes les zones (#.news),
  • tous les messages pour toutes les zones (#)

exemple 2

Mise en oeuvre avec RabbitMQ

On découpe la mise en pratique du besoin sur différents points :

  • les messages
  • les acteurs (producteurs et consommateurs)
  • les points d’échange
  • les clefs de routage et les files d’attente

Les messages

On distingue différents types de messages par leur famille d’utilisation :

  1. les messages de log Ce type de message est transformé dans une chaine d’opération pour permettre l’analyse ultérieure d’une situation. Le flux de messages est unidirectionnel. Généralement un traitement des messages en lot est possible.
  2. les messages interactifs Ce type de message est en fait une demande d’action et peut nécessiter une réponse. Le flux de messages est unidirectionnel. Généralement, un traitement le plus rapide possible est souhaité.

Les acteurs

Services produisant des messages :

Type Où ? Nom des services
log Local (machine) dns, mail, postgresql, syslog, ssh, web
log Distant (réseau LAN) relevé de température (arduino)
log Distant (internet) github, jira, twitter

Application consommant des messages :

Type Où ? Nom des services
log Local (machine) logstash
log Distant (réseau LAN) envois de mail
log Distant (internet) visualisation log en temps réel dans navigateur
app Local (machine) zonecheck (vérification config DNS), indexation site web, redimensionnement d’image

Organisation du broker de messages

La présence d’une interface d’administration pour rRabbitMQ permet de voir rapidement l’ensemble des points d’échanges et des files d’attentes. L’interface permet également de configurer les différents éléments ainsi que les relations.

Pour information, la configuration peut être effectuée par programme au travers des commandes AMQP définies dans le standard.

Point d’échange

Plusieurs solutions sont possibles pour faire communiquer tout ce monde :

  1. un point d’échange par type de message = 1 point d’échange “log” + 1 point d’échange “app”
  2. un point d’échange par type de service = plein de point d’échanges
  3. un mélange des autres solutions
Solution Avantage Inconvénient
1 rapide à mettre en place le routage est obligatoire pour différentier les services par la clef de routage
2 voir facilement le traffic par service (graph), routage simple longue liste de point d’échange
3 permet un maximum de souplesse nécessité de vérifier la configuration pour chaque point d’échange car potentiellement spécifique à celui-là

La solution 2 est celle sélectionnée ici.

Files d’attente

Dans l’optique d’uniformiser la configuration voici les propriétés appliquées :

  • pour chaque point d’échange une file d’attente nommée est créée
  • les messages insérés dans une file d’attente nommée expirent automatiquement
  • la durée d’expiration des messages est suffisamment grande pour qu’une maintenance de l’application consommatrice ne pose pas de perte de message
  • les files d’attente sont systématiquement associées à un point d’échange
  • les applications doivent valider la réception du message après leur traitement
  • les applications de visualisation doivent utiliser des files d’attentes anonymes (car elle n’ont pas d’opération à effectuer sur les messages)

Clef de routage

Dans la mesure du possible, il est conseillé de mettre dans la clef :

  • le nom complet de la machine (FQDN) de manière inversée (le TLD en premier).
  • le nom du service

Exemple de clefs :

  • “eu.r6d.machineA.srv_www”
  • “eu.r6d.machineB.srv_mail”
  • “local.mon-pc.srv_mail”

Lors de la récupération des messages dans des files d’attentes spécifiques à des applications, il sera possible de récupérer :

  • les messages du service mail par l’association de #.srv_mail
  • les messages du domaine r6d.eu par l’association de eu.r6d.#

Scalabilité de la solution

La croissance peut intervenir à plusieurs parties du système.

Voici quelques solutions pour arriver à suivre la demande :

Problème Partie concernée Solution
L’app consommatrice est trop lente sortie Ajouter une autre instance de l’application sur la même file d’attente. Les messages seront consommés en rounb robin
L’app consommatrice reçoit des messages qui ne l’interresse pas interne il faut appliquer un filtrage sur la clef de routage pour sélectionner plus finement les messages
Le serveur de message est lent interne N’y a-t-il pas trop de messages dans les files d’attente ? Il est possible d’augmenter les capacités avec une mise en cluster de RabbitMQ.
Le producteur n’envoie pas les messages aussi vite que d’habitude entrée RabbitMQ limite le débit en entrée lorsque les sorties sont saturée afin de limiter le nombre de messages en file d’attente. Essayer de consommer les messages plus rapidement.

Schéma

schéma d'implémentation

Besoin d’un peu plus d’information pour comprendre ? c’est par là

Légende :

  • lien rouge –> indique que le schéma n’est pas terminé
  • lien orange –> protocole STOMP
  • lien jaune –>
  • lien vert –> protocole MQTT
  • lien bleu –> protocole AMQP

En cours

  • différents modes de routage de messages

exemple 1

Liens :

Acronymes :

MQS : Message Queing Service, service de gestion de message en file d’attente

Licence

logo creative common by-sa 3.0 Creative Commons Paternité – Partage à l’Identique 3.0 non transcrit