U ovom članku koristimo udariti, ssh, lučki radnik и Nginx Organizirat ćemo besprijekoran izgled web aplikacije. Plavo-zeleni raspored je tehnika koja vam omogućuje trenutno ažuriranje aplikacije bez odbijanja i jednog zahtjeva. To je jedna od strategija implementacije bez prekida rada i najprikladnija je za aplikacije s jednom instancom, ali mogućnošću učitavanja druge instance spremne za rad u blizini.
Recimo da imate web aplikaciju s kojom mnogi klijenti aktivno rade, a apsolutno nema načina da legne na nekoliko sekundi. I stvarno trebate pokrenuti ažuriranje knjižnice, ispraviti bug ili novu cool značajku. U normalnoj situaciji morat ćete zaustaviti aplikaciju, zamijeniti je i ponovo pokrenuti. U slučaju dockera, možete ga prvo zamijeniti, zatim ponovno pokrenuti, ali će i dalje postojati period u kojem se zahtjevi prema aplikaciji neće obrađivati, jer obično aplikaciji treba neko vrijeme da se inicijalno učita. Što ako se pokrene, ali se pokaže neoperabilnim? To je problem, riješimo ga s minimalnim sredstvima i što elegantnije.
ODRICANJE OD ODGOVORNOSTI: Većina članka predstavljena je u eksperimentalnom formatu - u obliku snimke sesije na konzoli. Nadamo se da ovo neće biti previše teško razumjeti i da će se kod dovoljno dokumentirati. Za ugođaj, zamislite da to nisu samo isječci koda, već papir iz "željeznog" teletipa.
Zanimljive tehnike koje je teško guglati samo čitanjem koda opisane su na početku svakog odjeljka. Ako vam još nešto nije jasno, guglajte i provjerite. objasnite ljusku (srećom, opet radi, zbog deblokade telegrama). Ako ne možete ništa guglati, pitajte u komentarima. Rado ću dodati u odgovarajući odjeljak "Zanimljive tehnike".
Započnimo.
$ mkdir blue-green-deployment && cd $_
Usluga
Napravimo eksperimentalni servis i stavimo ga u kontejner.
Zanimljive tehnike
cat << EOF > file-name (Ovdje Dokument + I/O preusmjeravanje) je način stvaranja datoteke s više redaka jednom naredbom. Sve iz čega bash čita /dev/stdin iza ovog retka i prije retka EOF bit će zabilježeno u file-name.
wget -qO- URL (objasnite ljusku) — izlaz dokumenta primljenog putem HTTP-a na /dev/stdout (analogno curl URL).
Ispis
Posebno prekidam isječak kako bih omogućio isticanje za Python. Na kraju će biti još jedan ovakav komad. Uzmite u obzir da je na tim mjestima papir izrezan kako bi se poslao u odjel za isticanje (gdje je šifra ručno bojana markerima), a zatim su ti komadi zalijepljeni natrag.
$ cat << EOF > uptimer.py
from http.server import BaseHTTPRequestHandler, HTTPServer
from time import monotonic
app_version = 1
app_name = f'Uptimer v{app_version}.0'
loading_seconds = 15 - app_version * 5
class Handler(BaseHTTPRequestHandler):
def do_GET(self):
if self.path == '/':
try:
t = monotonic() - server_start
if t < loading_seconds:
self.send_error(503)
else:
self.send_response(200)
self.send_header('Content-Type', 'text/html')
self.end_headers()
response = f'<h2>{app_name} is running for {t:3.1f} seconds.</h2>n'
self.wfile.write(response.encode('utf-8'))
except Exception:
self.send_error(500)
else:
self.send_error(404)
httpd = HTTPServer(('', 8080), Handler)
server_start = monotonic()
print(f'{app_name} (loads in {loading_seconds} sec.) started.')
httpd.serve_forever()
EOF
$ cat << EOF > Dockerfile
FROM python:alpine
EXPOSE 8080
COPY uptimer.py app.py
CMD [ "python", "-u", "./app.py" ]
EOF
$ docker build --tag uptimer .
Sending build context to Docker daemon 39.42kB
Step 1/4 : FROM python:alpine
---> 8ecf5a48c789
Step 2/4 : EXPOSE 8080
---> Using cache
---> cf92d174c9d3
Step 3/4 : COPY uptimer.py app.py
---> a7fbb33d6b7e
Step 4/4 : CMD [ "python", "-u", "./app.py" ]
---> Running in 1906b4bd9fdf
Removing intermediate container 1906b4bd9fdf
---> c1655b996fe8
Successfully built c1655b996fe8
Successfully tagged uptimer:latest
$ docker run --rm --detach --name uptimer --publish 8080:8080 uptimer
8f88c944b8bf78974a5727070a94c76aa0b9bb2b3ecf6324b784e782614b2fbf
$ docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
8f88c944b8bf uptimer "python -u ./app.py" 3 seconds ago Up 5 seconds 0.0.0.0:8080->8080/tcp uptimer
$ docker logs uptimer
Uptimer v1.0 (loads in 10 sec.) started.
$ wget -qSO- http://localhost:8080
HTTP/1.0 503 Service Unavailable
Server: BaseHTTP/0.6 Python/3.8.3
Date: Sat, 22 Aug 2020 19:52:40 GMT
Connection: close
Content-Type: text/html;charset=utf-8
Content-Length: 484
$ wget -qSO- http://localhost:8080
HTTP/1.0 200 OK
Server: BaseHTTP/0.6 Python/3.8.3
Date: Sat, 22 Aug 2020 19:52:45 GMT
Content-Type: text/html
<h2>Uptimer v1.0 is running for 15.4 seconds.</h2>
$ docker rm --force uptimer
uptimer
Obrnuti proxy
Kako bi se naša aplikacija mogla neprimjetno mijenjati, potrebno je da ispred nje postoji neki drugi entitet koji će sakriti svoju zamjenu. To bi mogao biti web poslužitelj Nginx в obrnuti proxy način. Između klijenta i aplikacije uspostavlja se obrnuti proxy. Prihvaća zahtjeve klijenata i prosljeđuje ih aplikaciji te prosljeđuje odgovore aplikacije klijentima.
Aplikacija i obrnuti proxy mogu se povezati unutar dockera pomoću docker mreža. Dakle, spremnik s aplikacijom čak ne treba prosljeđivati port na host sustavu, što omogućuje da aplikacija bude maksimalno izolirana od vanjskih prijetnji.
Ako obrnuti proxy živi na drugom glavnom računalu, morat ćete napustiti docker mrežu i povezati aplikaciju s obrnutim proxyjem putem mreže glavnog računala, prosljeđujući port aplikacije parametar --publish, kao kod prvog pokretanja i kao kod obrnutog proxyja.
Obrnuti proxy ćemo pokrenuti na portu 80, jer je to upravo entitet koji bi trebao slušati vanjsku mrežu. Ako je priključak 80 zauzet na vašem testnom hostu, promijenite parametar --publish 80:80 na --publish ANY_FREE_PORT:80.
$ docker network create web-gateway
5dba128fb3b255b02ac012ded1906b7b4970b728fb7db3dbbeccc9a77a5dd7bd
$ docker run --detach --rm --name uptimer --network web-gateway uptimer
a1105f1b583dead9415e99864718cc807cc1db1c763870f40ea38bc026e2d67f
$ docker run --rm --network web-gateway alpine wget -qO- http://uptimer:8080
<h2>Uptimer v1.0 is running for 11.5 seconds.</h2>
$ docker run --detach --publish 80:80 --network web-gateway --name reverse-proxy nginx:alpine
80695a822c19051260c66bf60605dcb4ea66802c754037704968bc42527bf120
$ docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
80695a822c19 nginx:alpine "/docker-entrypoint.…" 27 seconds ago Up 25 seconds 0.0.0.0:80->80/tcp reverse-proxy
a1105f1b583d uptimer "python -u ./app.py" About a minute ago Up About a minute 8080/tcp uptimer
$ cat << EOF > uptimer.conf
server {
listen 80;
location / {
proxy_pass http://uptimer:8080;
}
}
EOF
$ docker cp ./uptimer.conf reverse-proxy:/etc/nginx/conf.d/default.conf
$ docker exec reverse-proxy nginx -s reload
2020/06/23 20:51:03 [notice] 31#31: signal process started
$ wget -qSO- http://localhost
HTTP/1.1 200 OK
Server: nginx/1.19.0
Date: Sat, 22 Aug 2020 19:56:24 GMT
Content-Type: text/html
Transfer-Encoding: chunked
Connection: keep-alive
<h2>Uptimer v1.0 is running for 104.1 seconds.</h2>
Besprijekorna implementacija
Pustimo novu verziju aplikacije (s dvostrukim povećanjem performansi pri pokretanju) i pokušajmo je neprimjetno implementirati.
Zanimljive tehnike
echo 'my text' | docker exec -i my-container sh -c 'cat > /my-file.txt' — Napišite tekst my text podnijeti /my-file.txt unutar kontejnera my-container.
$ sed -i "s/app_version = 1/app_version = 2/" uptimer.py
$ docker build --tag uptimer .
Sending build context to Docker daemon 39.94kB
Step 1/4 : FROM python:alpine
---> 8ecf5a48c789
Step 2/4 : EXPOSE 8080
---> Using cache
---> cf92d174c9d3
Step 3/4 : COPY uptimer.py app.py
---> 3eca6a51cb2d
Step 4/4 : CMD [ "python", "-u", "./app.py" ]
---> Running in 8f13c6d3d9e7
Removing intermediate container 8f13c6d3d9e7
---> 1d56897841ec
Successfully built 1d56897841ec
Successfully tagged uptimer:latest
$ docker run --detach --rm --name uptimer_BLUE --network web-gateway uptimer
96932d4ca97a25b1b42d1b5f0ede993b43f95fac3c064262c5c527e16c119e02
$ docker logs uptimer_BLUE
Uptimer v2.0 (loads in 5 sec.) started.
$ docker run --rm --network web-gateway alpine wget -qO- http://uptimer_BLUE:8080
<h2>Uptimer v2.0 is running for 23.9 seconds.</h2>
$ sed s/uptimer/uptimer_BLUE/ uptimer.conf | docker exec --interactive reverse-proxy sh -c 'cat > /etc/nginx/conf.d/default.conf'
$ docker exec reverse-proxy cat /etc/nginx/conf.d/default.conf
server {
listen 80;
location / {
proxy_pass http://uptimer_BLUE:8080;
}
}
$ docker exec reverse-proxy nginx -s reload
2020/06/25 21:22:23 [notice] 68#68: signal process started
$ wget -qO- http://localhost
<h2>Uptimer v2.0 is running for 63.4 seconds.</h2>
$ docker rm -f uptimer
uptimer
$ wget -qO- http://localhost
<h2>Uptimer v2.0 is running for 84.8 seconds.</h2>
$ docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
96932d4ca97a uptimer "python -u ./app.py" About a minute ago Up About a minute 8080/tcp uptimer_BLUE
80695a822c19 nginx:alpine "/docker-entrypoint.…" 8 minutes ago Up 8 minutes 0.0.0.0:80->80/tcp reverse-proxy
U ovoj fazi, slika se gradi izravno na poslužitelju, što zahtijeva da izvori aplikacije budu tamo, a također opterećuje poslužitelj nepotrebnim radom. Sljedeći korak je dodijeliti sklop slike zasebnom stroju (na primjer, CI sustavu) i zatim ga prenijeti na poslužitelj.
Prijenos slika
Nažalost, nema smisla prenositi slike s lokalnog hosta na lokalni host, tako da ovaj odjeljak možete istražiti samo ako imate dva hosta s Dockerom pri ruci. U najmanju ruku to izgleda otprilike ovako:
$ ssh production-server docker image ls
REPOSITORY TAG IMAGE ID CREATED SIZE
$ docker image save uptimer | ssh production-server 'docker image load'
Loaded image: uptimer:latest
$ ssh production-server docker image ls
REPOSITORY TAG IMAGE ID CREATED SIZE
uptimer latest 1d56897841ec 5 minutes ago 78.9MB
Momčad docker save sprema slikovne podatke u .tar arhivu, što znači da teži oko 1.5 puta više nego što bi težio u komprimiranom obliku. Pa protresimo to u ime uštede vremena i prometa:
Sakupimo sada sve što smo ručno napravili u jednu skriptu. Počnimo s funkcijom najviše razine, a zatim pogledajmo ostale koje se u njoj koriste.
Zanimljive tehnike
${parameter?err_msg} - jedna od bash magičnih čarolija (aka zamjena parametara). Ako parameter nije navedeno, izlaz err_msg i izađite s kodom 1.
docker --log-driver journald — prema zadanim postavkama, upravljački program za bilježenje dockera je tekstualna datoteka bez ikakve rotacije. Ovim pristupom dnevnici brzo popune cijeli disk, pa je za proizvodno okruženje potrebno promijeniti upravljački program na pametniji.
Skripta za implementaciju
deploy() {
local usage_msg="Usage: ${FUNCNAME[0]} image_name"
local image_name=${1?$usage_msg}
ensure-reverse-proxy || return 2
if get-active-slot $image_name
then
local OLD=${image_name}_BLUE
local new_slot=GREEN
else
local OLD=${image_name}_GREEN
local new_slot=BLUE
fi
local NEW=${image_name}_${new_slot}
echo "Deploying '$NEW' in place of '$OLD'..."
docker run
--detach
--restart always
--log-driver journald
--name $NEW
--network web-gateway
$image_name || return 3
echo "Container started. Checking health..."
for i in {1..20}
do
sleep 1
if get-service-status $image_name $new_slot
then
echo "New '$NEW' service seems OK. Switching heads..."
sleep 2 # Ensure service is ready
set-active-slot $image_name $new_slot || return 4
echo "'$NEW' service is live!"
sleep 2 # Ensure all requests were processed
echo "Killing '$OLD'..."
docker rm -f $OLD
docker image prune -f
echo "Deployment successful!"
return 0
fi
echo "New '$NEW' service is not ready yet. Waiting ($i)..."
done
echo "New '$NEW' service did not raise, killing it. Failed to deploy T_T"
docker rm -f $NEW
return 5
}
Korištene značajke:
ensure-reverse-proxy — Provjerava radi li obrnuti proxy (korisno za prvu implementaciju)
get-active-slot service_name — Određuje koji je utor trenutno aktivan za određenu uslugu (BLUE ili GREEN)
get-service-status service_name deployment_slot — Određuje je li usluga spremna za obradu dolaznih zahtjeva
set-active-slot service_name deployment_slot — Mijenja nginx konfiguraciju u obrnutom proxy spremniku
U cilju:
ensure-reverse-proxy() {
is-container-up reverse-proxy && return 0
echo "Deploying reverse-proxy..."
docker network create web-gateway
docker run
--detach
--restart always
--log-driver journald
--name reverse-proxy
--network web-gateway
--publish 80:80
nginx:alpine || return 1
docker exec --interactive reverse-proxy sh -c "> /etc/nginx/conf.d/default.conf"
docker exec reverse-proxy nginx -s reload
}
is-container-up() {
local container=${1?"Usage: ${FUNCNAME[0]} container_name"}
[ -n "$(docker ps -f name=${container} -q)" ]
return $?
}
get-active-slot() {
local service=${1?"Usage: ${FUNCNAME[0]} service_name"}
if is-container-up ${service}_BLUE && is-container-up ${service}_GREEN; then
echo "Collision detected! Stopping ${service}_GREEN..."
docker rm -f ${service}_GREEN
return 0 # BLUE
fi
if is-container-up ${service}_BLUE && ! is-container-up ${service}_GREEN; then
return 0 # BLUE
fi
if ! is-container-up ${service}_BLUE; then
return 1 # GREEN
fi
}
get-service-status() {
local usage_msg="Usage: ${FUNCNAME[0]} service_name deployment_slot"
local service=${1?usage_msg}
local slot=${2?$usage_msg}
case $service in
# Add specific healthcheck paths for your services here
*) local health_check_port_path=":8080/" ;;
esac
local health_check_address="http://${service}_${slot}${health_check_port_path}"
echo "Requesting '$health_check_address' within the 'web-gateway' docker network:"
docker run --rm --network web-gateway alpine
wget --timeout=1 --quiet --server-response $health_check_address
return $?
}
set-active-slot() {
local usage_msg="Usage: ${FUNCNAME[0]} service_name deployment_slot"
local service=${1?$usage_msg}
local slot=${2?$usage_msg}
[ "$slot" == BLUE ] || [ "$slot" == GREEN ] || return 1
get-nginx-config $service $slot | docker exec --interactive reverse-proxy sh -c "cat > /etc/nginx/conf.d/$service.conf"
docker exec reverse-proxy nginx -t || return 2
docker exec reverse-proxy nginx -s reload
}
Funkcija get-active-slot zahtijeva malo objašnjenje:
Zašto vraća broj, a ne ispisuje niz?
U svakom slučaju, u pozivnoj funkciji provjeravamo rezultat njezina rada, a provjera izlaznog koda korištenjem bash-a puno je lakša od provjere niza. Osim toga, dobivanje niza iz njega vrlo je jednostavno: get-active-slot service && echo BLUE || echo GREEN.
Jesu li tri uvjeta doista dovoljna za razlikovanje svih stanja?
I dva će biti dovoljna, zadnji je tu samo radi kompletnosti, da ne pišem else.
Samo funkcija koja vraća nginx konfiguracije ostaje nedefinirana: get-nginx-config service_name deployment_slot. Po analogiji s provjerom zdravlja, ovdje možete postaviti bilo koju konfiguraciju za bilo koju uslugu. Od zanimljivosti - samo cat <<- EOF, što vam omogućuje uklanjanje svih kartica na početku. Istina, cijena dobrog oblikovanja su pomiješani tabulatori s razmacima, što se danas smatra vrlo lošim oblikom. Ali bash forsira kartice, a također bi bilo lijepo imati normalno formatiranje u nginx konfiguraciji. Ukratko, miješanje tabova s razmacima ovdje se doista čini kao najbolje rješenje od najgoreg. Međutim, ovo nećete vidjeti u isječku ispod, budući da Habr "to dobro radi" mijenjajući sve kartice u 4 razmaka i EOF čineći nevažećim. I ovdje je to uočljivo.
Kako ne bih ustao dvaput, odmah ću vam reći o tome cat << 'EOF', s kojim ćemo se susresti kasnije. Ako pišete jednostavno cat << EOF, tada se unutar heredoc niz interpolira (varijable se proširuju ($foo), pozivi naredbi ($(bar)) itd.), a ako kraj dokumenta stavite u jednostruke navodnike, interpolacija je onemogućena i simbol $ prikazuje se kakav jest. Što vam je potrebno za umetanje skripte u drugu skriptu.
get-nginx-config() {
local usage_msg="Usage: ${FUNCNAME[0]} service_name deployment_slot"
local service=${1?$usage_msg}
local slot=${2?$usage_msg}
[ "$slot" == BLUE ] || [ "$slot" == GREEN ] || return 1
local container_name=${service}_${slot}
case $service in
# Add specific nginx configs for your services here
*) nginx-config-simple-service $container_name:8080 ;;
esac
}
nginx-config-simple-service() {
local usage_msg="Usage: ${FUNCNAME[0]} proxy_pass"
local proxy_pass=${1?$usage_msg}
cat << EOF
server {
listen 80;
location / {
proxy_pass http://$proxy_pass;
}
}
EOF
}
Ovo je cijeli scenarij. I tako bit s ovom skriptom za preuzimanje putem wget-a ili curla.
Izvršavanje parametriziranih skripti na udaljenom poslužitelju
Vrijeme je da pokucate na ciljni poslužitelj. Ovaj put localhost sasvim prikladno:
$ ssh-copy-id localhost
/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed
/usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys
himura@localhost's password:
Number of key(s) added: 1
Now try logging into the machine, with: "ssh 'localhost'"
and check to make sure that only the key(s) you wanted were added.
Napisali smo skriptu za implementaciju koja preuzima unaprijed izgrađenu sliku na ciljni poslužitelj i neprimjetno zamjenjuje spremnik usluge, ali kako je možemo izvršiti na udaljenom računalu? Skripta ima argumente, budući da je univerzalna i može implementirati nekoliko usluga odjednom pod jednim obrnutim proxyjem (možete koristiti nginx konfiguracije da odredite koji će url biti koja usluga). Skripta se ne može pohraniti na poslužitelj, jer je u tom slučaju nećemo moći automatski ažurirati (u svrhu ispravljanja grešaka i dodavanja novih usluga), i općenito, stanje = zlo.
Rješenje 1: I dalje pohranite skriptu na poslužitelj, ali je kopirajte svaki put scp. Zatim se povežite putem ssh i izvrši skriptu s potrebnim argumentima.
Cons:
Dvije akcije umjesto jedne
Možda ne postoji mjesto gdje kopirate, ili mu možda nema pristupa, ili se skripta može izvršiti u vrijeme zamjene.
Preporučljivo je počistiti za sobom (izbrisati skriptu).
Već tri akcije.
Rješenje 2:
Zadržite samo definicije funkcija u skripti i ne pokrećite ništa
S sed dodajte poziv funkcije na kraj
Pošalji sve izravno na shh putem cijevi (|)
Pros:
Stvarno bez državljanstva
Nema standardnih entiteta
Osjećaj cool
Učinimo to bez Ansiblea. Da, sve je već izmišljeno. Da, bicikl. Pogledajte kako je bicikl jednostavan, elegantan i minimalistički:
$ cat << 'EOF' > deploy.sh
#!/bin/bash
usage_msg="Usage: $0 ssh_address local_image_tag"
ssh_address=${1?$usage_msg}
image_name=${2?$usage_msg}
echo "Connecting to '$ssh_address' via ssh to seamlessly deploy '$image_name'..."
( sed "$a deploy $image_name" | ssh -T $ssh_address ) << 'END_OF_SCRIPT'
deploy() {
echo "Yay! The '${FUNCNAME[0]}' function is executing on '$(hostname)' with argument '$1'"
}
END_OF_SCRIPT
EOF
$ chmod +x deploy.sh
$ ./deploy.sh localhost magic-porridge-pot
Connecting to localhost...
Yay! The 'deploy' function is executing on 'hut' with argument 'magic-porridge-pot'
Međutim, ne možemo biti sigurni da udaljeni host ima odgovarajući bash, pa ćemo dodati malu provjeru na početku (ovo je umjesto granatiranje):
if [ "$SHELL" != "/bin/bash" ]
then
echo "The '$SHELL' shell is not supported by 'deploy.sh'. Set a '/bin/bash' shell for '$USER@$HOSTNAME'."
exit 1
fi
A sada je stvarno:
$ docker exec reverse-proxy rm /etc/nginx/conf.d/default.conf
$ wget -qO deploy.sh https://git.io/JUURc
$ chmod +x deploy.sh
$ ./deploy.sh localhost uptimer
Sending gzipped image 'uptimer' to 'localhost' via ssh...
Loaded image: uptimer:latest
Connecting to 'localhost' via ssh to seamlessly deploy 'uptimer'...
Deploying 'uptimer_GREEN' in place of 'uptimer_BLUE'...
06f5bc70e9c4f930e7b1f826ae2ca2f536023cc01e82c2b97b2c84d68048b18a
Container started. Checking health...
Requesting 'http://uptimer_GREEN:8080/' within the 'web-gateway' docker network:
HTTP/1.0 503 Service Unavailable
wget: server returned error: HTTP/1.0 503 Service Unavailable
New 'uptimer_GREEN' service is not ready yet. Waiting (1)...
Requesting 'http://uptimer_GREEN:8080/' within the 'web-gateway' docker network:
HTTP/1.0 503 Service Unavailable
wget: server returned error: HTTP/1.0 503 Service Unavailable
New 'uptimer_GREEN' service is not ready yet. Waiting (2)...
Requesting 'http://uptimer_GREEN:8080/' within the 'web-gateway' docker network:
HTTP/1.0 200 OK
Server: BaseHTTP/0.6 Python/3.8.3
Date: Sat, 22 Aug 2020 20:15:50 GMT
Content-Type: text/html
New 'uptimer_GREEN' service seems OK. Switching heads...
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful
2020/08/22 20:15:54 [notice] 97#97: signal process started
The 'uptimer_GREEN' service is live!
Killing 'uptimer_BLUE'...
uptimer_BLUE
Total reclaimed space: 0B
Deployment successful!
Sada možete otvoriti http://localhost/ u pregledniku ponovno pokrenite implementaciju i provjerite radi li besprijekorno ažuriranjem stranice prema CD-u tijekom izgleda.