make compliant with mistune update
This commit is contained in:
Yax
parent
fc61c0b9c7
commit
ae83dbaf80
30 changed files with 74 additions and 94 deletions
|
|
@ -10,7 +10,7 @@ des versions précédentes ou d'autres distrib les bonnes étapes pour Karmic.
|
|||
D'abord il faut installer le paquet usb-modeswitch fourni dans les dépôts
|
||||
standards (version actuelle 1.0.2-1) :
|
||||
|
||||
``` shell
|
||||
```shell
|
||||
sudo apt-get install usb-modeswitch
|
||||
```
|
||||
|
||||
|
|
@ -19,7 +19,7 @@ périphérique de stockage et non pas comme un périphérique de communication.
|
|||
C'est là que la usb-modeswitch intervient... Cette commande doit être
|
||||
lancée à chaque branchement de la clef :
|
||||
|
||||
``` shell
|
||||
```shell
|
||||
sudo usb_modeswitch --default-vendor 0x19d2 --default-product 0x2000
|
||||
--target-vendor 0X19d2 --target-product 0x0052 -s 8 --message-endpoint 0x01
|
||||
--message-content 55534243123456782000000080000c85010101180101010101000000000000
|
||||
|
|
|
|||
|
|
@ -20,7 +20,7 @@ fr.org/ffmpeg) pour ffmpeg apporte l'essentiel de la solution à part une
|
|||
coquille sur un paramètre et le nom des librairies h264 qu'il faut adapter. La
|
||||
commande ultime est donc :
|
||||
|
||||
``` shell
|
||||
```shell
|
||||
ffmpeg -i [input_file] -r 29.97 -vcodec libx264 -s 640x480 -aspect 16:9 -flags +loop -cmp
|
||||
+chroma -deblockalpha 0 -deblockbeta 0 -b 768k -maxrate 1500k -bufsize 4M -bt 256k
|
||||
-refs 1 -bf 3 -coder 1 -me_method umh -me_range 16 -subq 7
|
||||
|
|
|
|||
|
|
@ -8,7 +8,7 @@ rajouter le mode dynamiquement. J'ai privilégié la seconde option. La commande
|
|||
gtf permet de calculer les bons paramètres en fonction d'une résolution et
|
||||
d'un taux de rafraîchissement :
|
||||
|
||||
``` shell
|
||||
```shell
|
||||
$ gtf 1280 800 60
|
||||
# 1280x800 @ 60.00 Hz (GTF) hsync: 49.68 kHz; pclk: 83.46 MHz
|
||||
Modeline "1280x800_60.00" 83.46 1280 1344 1480 1680 800 801 804 828 -HSync +Vsync
|
||||
|
|
@ -17,7 +17,7 @@ Modeline "1280x800_60.00" 83.46 1280 1344 1480 1680 800 801 804 828 -HSy
|
|||
Le résultat peut être passé à la commande xrandr pour ajouter le mode
|
||||
dynamiquement. Voici le script complet à exécuter au démarrage :
|
||||
|
||||
``` shell
|
||||
```shell
|
||||
xrandr --newmode "1280x800_60.00" 83.46 1280 1344 1480 1680 800 801 804 828 -HSync +Vsync
|
||||
xrandr --addmode LVDS1 "1280x800_60.00"
|
||||
xrandr --output LVDS1 --mode "1280x800_60.00"
|
||||
|
|
|
|||
|
|
@ -20,13 +20,13 @@ CI](http://jenkins-ci.org/) dans le conteneur de Servlet
|
|||
[Tomcat](http://tomcat.apache.org/) sous Ubuntu Server 10.4. D'abord on installe
|
||||
Tomcat 6 avec le système de paquets :
|
||||
|
||||
``` shell
|
||||
```shell
|
||||
sudo apt-get install tomcat6
|
||||
```
|
||||
|
||||
Ensuite on installe manuellement le WAR de Jenkins CI :
|
||||
|
||||
``` shell
|
||||
```shell
|
||||
# move to tomcat webapps dir
|
||||
cd /var/lib/tomcat6/webapps
|
||||
sudo wget http://mirrors.jenkins-ci.org/war/latest/jenkins.war
|
||||
|
|
@ -35,7 +35,7 @@ sudo wget http://mirrors.jenkins-ci.org/war/latest/jenkins.war
|
|||
Si Tomcat était lancé, Jenkins va être déployé et disponible en quelques
|
||||
secondes. Sinon démarrez Tomcat :
|
||||
|
||||
``` shell
|
||||
```shell
|
||||
sudo /etc/init.d/tomcat6 start
|
||||
```
|
||||
|
||||
|
|
|
|||
|
|
@ -44,7 +44,7 @@ qui appelle le script PERL de teebeenator et qui sauve les donnée dans un
|
|||
fichier texte. Cette collecte est réalisée toutes les 5 minutes grâce à
|
||||
CRON.
|
||||
|
||||
``` shell
|
||||
```shell
|
||||
perl livebox.pl --user=admin --pass=<VotreMotDePasse>
|
||||
-page=infosys_main -v 2>/dev/null | html2text >/adsl_stats.txt
|
||||
```
|
||||
|
|
@ -68,7 +68,7 @@ unités, le libellé de chaque variable graphée
|
|||
Voici shell script du plugin adsl_download qui collecte la valeur de la bande
|
||||
passante descendante :
|
||||
|
||||
``` shell
|
||||
```shell
|
||||
if [ $# = 1 ]; then
|
||||
echo "graph_title Bandwidth - Download"
|
||||
echo "graph_category ADSL"
|
||||
|
|
|
|||
|
|
@ -21,7 +21,7 @@ le développement d'un logiciel écrit en Java qui utilise le système de build
|
|||
[Apache Maven](http://fr.wikipedia.org/wiki/Apache_Maven) pour construire le
|
||||
projet. D'abord il faut installer Maven
|
||||
|
||||
``` shell
|
||||
```shell
|
||||
$ apt-get install maven2
|
||||
```
|
||||
|
||||
|
|
|
|||
|
|
@ -21,7 +21,7 @@ exécutables pour Fedora
|
|||
|
||||
Voici le source du fichier INSTALL
|
||||
|
||||
``` shell
|
||||
```shell
|
||||
cp tuxboot.pro tuxboot-pro.bak
|
||||
sed -i '/^RESOURCES/d' tuxboot.pro
|
||||
lupdate-qt4 tuxboot.pro
|
||||
|
|
|
|||
|
|
@ -16,7 +16,7 @@ télécharger les sources Python. Les manipulations suivantes sont réalisées
|
|||
sur une Debian 6 avec Python, Nginx et OpenSSH installés.
|
||||
|
||||
|
||||
``` shell
|
||||
```shell
|
||||
# on installe sous /srv
|
||||
cd /srv
|
||||
wget http://sourceforge.net/projects/sabnzbdplus/files/sabnzbdplus/0.7.6/
|
||||
|
|
@ -32,7 +32,7 @@ générale et **aussi restreindre l'adresse d'écoute** à l'interface localhost
|
|||
allons mettre en place par la suite. On peut automatiser le démarrage en
|
||||
rajoutant un script sabnzbd sous /etc/init.d tel que celui-ci :
|
||||
|
||||
``` shell
|
||||
```shell
|
||||
### BEGIN INIT INFO
|
||||
# Provides: sabnzd
|
||||
# Required-Start: $local_fs $remote_fs
|
||||
|
|
@ -80,7 +80,7 @@ On active ce script sous Debian avec update-rc.d sabnzbd defaults. Finalement on
|
|||
configure Nginx comme proxy. Je me suis borné à un accès HTTP protégé par
|
||||
une authentification utilisateur / mot de passe mais HTTPS est recommandé.
|
||||
|
||||
``` nginx
|
||||
```nginx
|
||||
server {
|
||||
listen 80;
|
||||
server_name www.yourserver.yourdomain;
|
||||
|
|
@ -107,7 +107,7 @@ Nginx. A ce stade SABnzbd fonctionne à moitié :-) En effet SABnzbd ne va pas
|
|||
servir toutes les ressources (HTML / CSS) et il faut les lier statiquement à
|
||||
Nginx.
|
||||
|
||||
``` shell
|
||||
```shell
|
||||
# on lie les ressources statiques du thème Plush
|
||||
mkdir -p /var/www/www/sabnzbd
|
||||
ln -s /srv/sabnzbd/interfaces/Plush/templates/static /var/www/www/sabnzbd/static
|
||||
|
|
|
|||
|
|
@ -78,7 +78,7 @@ leur fonctionnement en groupe. Pour cela, on doit générer une clef d'authenfic
|
|||
les noeuds du cluster. L'utilitaire **corosync-keygen** permet de générer cette clef à partir d'entrées clavier
|
||||
pseudo-aléatoires qu'il faut ensuite sécuriser et copier sur les autres noeuds.
|
||||
|
||||
``` shell
|
||||
```shell
|
||||
# génération de la clef depuis vm-node1
|
||||
corosync-keygen
|
||||
mv authkey /etc/corosync/authkey
|
||||
|
|
@ -217,7 +217,7 @@ Vous remarquerez qu'on va plus loin que la définition d'une ressource Apache. L
|
|||
Pacemaker d'utiliser la page de statut d'Apache pour décider d'une bascule. Il ne faut donc pas oublier de
|
||||
configurer cette URL dans Apache pour que cela fonctionne :
|
||||
|
||||
``` apache
|
||||
```apache
|
||||
<Location /server-status>
|
||||
SetHandler server-status
|
||||
Order deny,allow
|
||||
|
|
|
|||
|
|
@ -31,7 +31,7 @@ avoir une trace des fichiers synchronisés. J'ai dégoté le programme [blat](ht
|
|||
pour l'envoi d'email facile depuis un batch, il y en a sûrement plein d'autres. Voici un
|
||||
script batch assez proche de celui que j'utilise :
|
||||
|
||||
``` bat
|
||||
```bat
|
||||
REM ================================================================
|
||||
REM Synchroniser les changements
|
||||
REM ================================================================
|
||||
|
|
|
|||
|
|
@ -54,7 +54,7 @@ L'installation de PEAR sur Debian est galette.
|
|||
Puis, on enregistre le canal Horde sur Pear et on installe les composants
|
||||
nécessaires :
|
||||
|
||||
``` shell
|
||||
```shell
|
||||
mkdir -p /var/www/horde
|
||||
cd /var/www/horde
|
||||
pear channel-discover pear.horde.org
|
||||
|
|
@ -74,7 +74,7 @@ Dans le cas de NginX sur Debian, il faut ajuster les permissions du répertoire.
|
|||
Et il faut créer les fichiers de configuration de chaque application à partir
|
||||
des modèles fournis :
|
||||
|
||||
``` shell
|
||||
```shell
|
||||
cd /var/www/horde/config
|
||||
for f in *.dist; do cp $f `basename $f .dist`; done
|
||||
cd /var/www/horde/kronolith/config
|
||||
|
|
@ -90,7 +90,7 @@ for f in *.dist; do cp $f `basename $f .dist`; done
|
|||
Il reste à configurer NginX. Je force l'utilisation de HTTPS en redirigeant les
|
||||
requêtes HTTP vers la version sécurisée du site.
|
||||
|
||||
``` nginx
|
||||
```nginx
|
||||
server {
|
||||
listen 80;
|
||||
server_name groupware.exemple.fr;
|
||||
|
|
|
|||
|
|
@ -34,7 +34,7 @@ Il faut remplacer *0* par *127.0.0.1* dans le fichier
|
|||
|
||||
Voici la version modifiée :
|
||||
|
||||
``` shell
|
||||
```shell
|
||||
QMAILDUID=`id -u qmaild`
|
||||
NOFILESGID=`id -g qmaild`
|
||||
MAXSMTPD=`cat /var/lib/qmail/control/concurrencyincoming`
|
||||
|
|
|
|||
|
|
@ -152,7 +152,7 @@ nouveau s'adresser aux sentinelles pour récupérer l'adresse du Redis maître.
|
|||
|
||||
Voici un exemple typique de code en Python :
|
||||
|
||||
``` python
|
||||
```python
|
||||
from redis.sentinel import Sentinel
|
||||
sentinel = Sentinel(
|
||||
[('192.168.0.51', 26379), ('192.168.0.52', 6379)], socket_timeout=0.1)
|
||||
|
|
|
|||
|
|
@ -28,7 +28,7 @@ l'arrêt fiable du processus en manipulant son PID.
|
|||
Voici un exemple de script d'init à la sauce Debian pour un programme
|
||||
JAVA :
|
||||
|
||||
``` shell
|
||||
```shell
|
||||
### BEGIN INIT INFO
|
||||
# Provides: monprog
|
||||
# Required-Start: $local_fs $remote_fs $network $syslog
|
||||
|
|
@ -185,7 +185,7 @@ Dans cet exemple, on envoie un signal SIGINT à monprog pour lui demander un arr
|
|||
|
||||
#### Interception d'un signal SIGINT en JAVA
|
||||
|
||||
``` java
|
||||
```java
|
||||
// register a shutdown hook
|
||||
Runtime.getRuntime().addShutdownHook(new Thread() {
|
||||
@Override
|
||||
|
|
|
|||
|
|
@ -17,7 +17,7 @@ En pré-requis, on suppose que Qemu est installé sur le système hôte. On
|
|||
vérifie que le processeur ARM du Raspberry est supporté par Qemu avec la
|
||||
commande suivante :
|
||||
|
||||
``` shell
|
||||
```shell
|
||||
$ qemu-system-arm -cpu ?
|
||||
```
|
||||
|
||||
|
|
@ -34,7 +34,7 @@ La modification d'un fichier est nécessaire pour que la distribution
|
|||
fonctionne avec Qemu. On effectue donc un premier démarrage particulier avec
|
||||
BASH en processus INIT pour la réaliser.
|
||||
|
||||
``` shell
|
||||
```shell
|
||||
$ qemu-system-arm -kernel kernel-qemu -cpu arm1176 -m 256 -M versatilepb -no-reboot -serial stdio -append "root=/dev/sda2 panic=1 rootfstype=ext4 rw init=/bin/bash" -hda 2014-06-20-wheezy-raspbian.img
|
||||
```
|
||||
|
||||
|
|
@ -66,7 +66,7 @@ D'abord on élargit le disque avec l'utilitaire qemu-resize.
|
|||
|
||||
Ensuite on démarre la Raspbian avec Qemu
|
||||
|
||||
``` shell
|
||||
```shell
|
||||
$ qemu-system-arm -kernel kernel-qemu -cpu arm1176 -m 256 -M versatilepb -no-reboot -serial stdio -append "root=/dev/sda2 panic=1 rootfstype=ext4 rw" -hda 2014-06-20-wheezy-raspbian.img
|
||||
```
|
||||
|
||||
|
|
|
|||
|
|
@ -37,7 +37,7 @@ codes](https://wiki.archlinux.org/index.php/Color_Bash_Prompt). Il ne faut pas
|
|||
oublier de réinitialiser la couleur en fin de prompt pour que ça ne coule pas
|
||||
sur le reste de la ligne avec un reset. je suis adepte des prompts concis :
|
||||
|
||||
``` shell
|
||||
```shell
|
||||
White='\e[0;37m' # White
|
||||
Red='\e[0;31m' # Red
|
||||
Reset=$(tput sgr0)
|
||||
|
|
@ -55,7 +55,7 @@ est un parfait exemple facile à configurer.
|
|||
les alias sont des substitutions de commandes. On peut les utiliser pour éviter
|
||||
de mémoriser des paramètres compliquées en définissant de nouvelles commandes :
|
||||
|
||||
``` shell
|
||||
```shell
|
||||
alias la='ll -A' # 'la' : voir les fichiers cachés
|
||||
alias lk='ls -lSr' # 'lk' : trier par taille
|
||||
```
|
||||
|
|
@ -63,7 +63,7 @@ alias lk='ls -lSr' # 'lk' : trier par taille
|
|||
Ou bien on peut redéfinir le comportement d'une commande en créant un alias du
|
||||
même nom forçant des paramètres :
|
||||
|
||||
``` shell
|
||||
```shell
|
||||
# forcer une demande de confirmation pour éviter les boulettes
|
||||
alias rm='rm --interactive --verbose'
|
||||
alias mv='mv --interactive --verbose'
|
||||
|
|
@ -77,7 +77,7 @@ exécutables accessibles dans le PATH (/usr/local/bin au hasard).
|
|||
|
||||
Voici les deux fonctions que j'utilise assez régulièrement :
|
||||
|
||||
``` shell
|
||||
```shell
|
||||
function bak() { cp "$1" "$1_`date +%Y-%m-%d_%H-%M-%S`" ; }
|
||||
|
||||
function extract() # Handy Extract Program
|
||||
|
|
@ -111,7 +111,7 @@ bashrc testent si dircolors est présent et l'utilise en rajoutant --color à
|
|||
ls par le biais d'un... alias (bravo à ceux qui n'ont pas lâché). Généralement,
|
||||
on a une section de ce genre dans notre .bashrc :
|
||||
|
||||
``` shell
|
||||
```shell
|
||||
# enable color support of ls
|
||||
if [ -x /usr/bin/dircolors ]; then
|
||||
test -r ~/.dircolors && eval "$(dircolors -b ~/.dircolors)" || eval "$(dircolors -b)"
|
||||
|
|
@ -204,7 +204,7 @@ pour l'affichage des répertoire mais en style non gras, je mets par contre en
|
|||
gras les répertoire ouverts à tous les vents (avec les droits d'écriture sur le
|
||||
groupe *other*), et en rouge non gras les fichiers exécutables.
|
||||
|
||||
``` shell
|
||||
```shell
|
||||
export LS_COLORS="di=00;34:ow=01;34:ex=00;31"
|
||||
```
|
||||
|
||||
|
|
|
|||
|
|
@ -21,7 +21,7 @@ Python dans un *virtualenv* de préférence, avec le gestionnaire de paquets
|
|||
|
||||
Voici un exemple d'envoi d'e-mail en Python :
|
||||
|
||||
``` python
|
||||
```python
|
||||
import requests
|
||||
headers = {'Content-Type': 'application/json; charset=utf-8'}
|
||||
msg = {
|
||||
|
|
@ -38,7 +38,7 @@ else:
|
|||
|
||||
Et voici le même exemple en ligne de commande avec CURL :
|
||||
|
||||
``` shell
|
||||
```shell
|
||||
curl -X POST -H "Content-Type: application/json; charset=utf-8"
|
||||
-d '{"to":"bill@phoenix.com", "subject":"Got it",
|
||||
"content":"See you soon!\n\n-- John"}'
|
||||
|
|
|
|||
|
|
@ -93,7 +93,7 @@ déroulée.
|
|||
|
||||
Voici donc les grandes lignes de la partie **récupération des données** :
|
||||
|
||||
``` shell
|
||||
```shell
|
||||
# Les fichiers de configuration de NginX
|
||||
cp -r /etc/nginx/* $TARGET_DIR/nginx/.
|
||||
|
||||
|
|
@ -119,7 +119,7 @@ synchronisée par Owncloud car on l'a copié en douce. Il faut forcer Owncloud
|
|||
rescanner son répertoire avec la commande suivante exécutée en tant
|
||||
qu'utilisateur *www-data*:
|
||||
|
||||
``` shell
|
||||
```shell
|
||||
su -c "/usr/bin/php /var/www/owncloud/console.php files:scan all" \
|
||||
-s /bin/sh www-data
|
||||
```
|
||||
|
|
|
|||
|
|
@ -157,7 +157,7 @@ le fichier */etc/fail2ban/action.d/sendmail-cron.conf* complet :
|
|||
|
||||
Dans mon cas, la tâche CRON est journalière :
|
||||
|
||||
``` shell
|
||||
```shell
|
||||
# fail2ban report
|
||||
@daily touch /var/run/fail2ban/mail.flag
|
||||
```
|
||||
|
|
|
|||
|
|
@ -40,7 +40,7 @@ ajoute la directive *display-setup-script* dans la section SeatDefaults :
|
|||
|
||||
et voici le script **lightdm-monitor.sh** :
|
||||
|
||||
``` shell
|
||||
```shell
|
||||
if (xrandr | grep "VGA1 disconnected"); then
|
||||
xrandr --output HDMI1 --off --output LVDS1 --mode 1366x768 --pos 0x0 \
|
||||
--rotate normal --output DP1 --off --output VGA1 --off
|
||||
|
|
@ -63,7 +63,7 @@ programme en ligne de commande de configurationde XFCE) adéquate.
|
|||
|
||||
Finalement, cela donne le script **xfce-monitor.sh** au démarrage de la session:
|
||||
|
||||
``` shell
|
||||
```shell
|
||||
sleep 3
|
||||
if (xrandr | grep "VGA1 disconnected"); then
|
||||
xrandr --output HDMI1 --off --output LVDS1 --mode 1366x768 --pos 0x0 \
|
||||
|
|
|
|||
|
|
@ -110,7 +110,7 @@ jour et envoie un e-mail par évènement avec le fichier ICS en pièce jointe.
|
|||
L'envoi est réalisé par l'utilitaire **mpack**. Le résultat final espéré pour
|
||||
notre exemple est ce script :
|
||||
|
||||
``` shell
|
||||
```shell
|
||||
#
|
||||
STARTDATE="`date -d '2015-09-14 10:30:00-000' '+%a %e %b %R'`"
|
||||
SUMMARY="Déjeuner avec M."
|
||||
|
|
@ -167,7 +167,7 @@ régulière.
|
|||
|
||||
Voci le script awk complet :
|
||||
|
||||
``` awk
|
||||
```awk
|
||||
BEGIN {
|
||||
FS="\n"
|
||||
OFS=""
|
||||
|
|
|
|||
|
|
@ -131,7 +131,7 @@ s'inspirant de [cette
|
|||
discussion](http://askubuntu.com/questions/360466/ubuntu-touch-officially-launched-version-how-to-sync-contacts)
|
||||
sur AskUbuntu. D'abord on configure syncevolution :
|
||||
|
||||
``` shell
|
||||
```shell
|
||||
# les valeurs username, password et syncurl doivent être adaptées
|
||||
syncevolution --keyring=no --configure --template webdav username=yax password=??? syncurl="mycloud.madyanne.fr" target-config@owncloud
|
||||
syncevolution --configure --template SyncEvolution_Client sync=none syncURL=local://@owncloud username= password= peerIsClient=1 owncloud
|
||||
|
|
@ -163,7 +163,7 @@ valeurs dans le shell script qu'on va lancer en CRON, merci
|
|||
[Alexandre](http://askubuntu.com/questions/611761/syncevolution-in-cronjob-to-sync-the-ubuntu-phone-via-caldav-arddav).
|
||||
Donc finalement c'est ce script qu'on va mettre sous CRON :
|
||||
|
||||
``` shell
|
||||
```shell
|
||||
export DISPLAY=:0.0
|
||||
export DBUS_SESSION_BUS_ADDRESS=$(ps -u phablet e | grep -Eo 'dbus-daemon.*address=unix:abstract=/tmp/dbus-[A-Za-z0-9]{10}' | tail -c35)
|
||||
syncevolution owncloud contacts
|
||||
|
|
|
|||
|
|
@ -64,7 +64,7 @@ port 80 alors qu'on l'attaque sur le port 8080. Un moyen de contourner ce
|
|||
problème si l'application n'est pas configurable, consiste à installer un NginX
|
||||
sur la machine hôte pour faire office de proxy.
|
||||
|
||||
``` nginx
|
||||
```nginx
|
||||
# Proxy
|
||||
|
||||
upstream vbox-vm {
|
||||
|
|
|
|||
|
|
@ -71,7 +71,7 @@ Golang pour gérer la concurrence de traitement.
|
|||
|
||||
Pour les fans de code, voici celui du serveur HTTP avec cache :
|
||||
|
||||
``` go
|
||||
```go
|
||||
package main
|
||||
|
||||
import (
|
||||
|
|
|
|||
|
|
@ -73,7 +73,7 @@ jette dans le puits, où il resteront... jusqu'au prochain redémarrage du serve
|
|||
|
||||
Voici le script en Korn Shell :
|
||||
|
||||
``` shell
|
||||
```shell
|
||||
#!/bin/ksh
|
||||
|
||||
if [ $# != 1 ]; then
|
||||
|
|
|
|||
|
|
@ -57,8 +57,7 @@ page.
|
|||
Voici le *template* Hugo des commentaires qui utilise la fonction **getJSON** pour récupérer les commentaires
|
||||
de la page en cours :
|
||||
|
||||
``` html
|
||||
{% raw %}
|
||||
```html
|
||||
<div id="stacosys-comments">
|
||||
{{ $restParam := (printf "/comments?token=%v&url=%v" .Site.Params.widgets.stacosys_token .URL) }}
|
||||
{{ $resp := getJSON .Site.Params.widgets.stacosys_url $restParam }}
|
||||
|
|
@ -79,14 +78,12 @@ de la page en cours :
|
|||
{{ .content | markdownify }}
|
||||
</p>
|
||||
{{ end }}
|
||||
</div>
|
||||
{% endraw %}
|
||||
</div>
|
||||
```
|
||||
|
||||
et un exemple de données renvoyée par Stacosys :
|
||||
|
||||
``` json
|
||||
{% raw %}
|
||||
```json
|
||||
{
|
||||
"data": [
|
||||
{
|
||||
|
|
@ -103,7 +100,6 @@ et un exemple de données renvoyée par Stacosys :
|
|||
}
|
||||
]
|
||||
}
|
||||
{% endraw %}
|
||||
```
|
||||
|
||||
Il reste une interaction entre le serveur HTTP et Stacosys pour poster des
|
||||
|
|
|
|||
|
|
@ -99,7 +99,7 @@ A ce niveau, on peut essayer de faire communiquer deux applications à travers R
|
|||
|
||||
Code du producteur :
|
||||
|
||||
``` python
|
||||
```python
|
||||
#!/usr/bin/env python
|
||||
import pika
|
||||
import sys
|
||||
|
|
@ -122,7 +122,7 @@ connection.close()
|
|||
|
||||
Code du consommateur :
|
||||
|
||||
``` python
|
||||
```python
|
||||
#!/usr/bin/env python
|
||||
import pika
|
||||
import sys
|
||||
|
|
|
|||
|
|
@ -20,7 +20,7 @@ A ce stade, vous pensez : *"c'est bizarre il ne nous a pas encore bassiné avec
|
|||
|
||||
La mise en prod a pris 15 minutes chrono : écriture d'un docker-compose en utilisant [mon image pour les applications Python](https://hub.docker.com/r/kianby/pythonapp/) et déploiement sur le serveur de containers.
|
||||
|
||||
``` docker
|
||||
```docker
|
||||
popforward:
|
||||
image: kianby/pythonapp:latest
|
||||
environment:
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue