diff --git a/Abbreviations/abbreviations.tex b/Abbreviations/abbreviations.tex
index b28f287..2f75d4d 100644
--- a/Abbreviations/abbreviations.tex
+++ b/Abbreviations/abbreviations.tex
@@ -12,6 +12,7 @@
 
 \textbf{BIOS} & \textbf{B}asic \textbf{I}nput/\textbf{O}utput \textbf{S}ystem \\
 
+\textbf{CaaS} & \textbf{C}ontainer \textbf{a}s \textbf{a} \textbf{S}ervice \\
 \textbf{CAPEC} & \textbf{C}ommon \textbf{A}ttack \textbf{P}attern \textbf{E}numeration and \textbf{C}lassification \\
 \textbf{CCE} & \textbf{C}ommon \textbf{C}onfiguration \textbf{E}numeration \\
 \textbf{CERT} & \textbf{C}omputer \textbf{E}mergency \textbf{R}esponse \textbf{T}eam \\
diff --git a/Abstract/abstractenglish.tex b/Abstract/abstractenglish.tex
index 451302c..8ce0f55 100644
--- a/Abstract/abstractenglish.tex
+++ b/Abstract/abstractenglish.tex
@@ -45,7 +45,7 @@ goal of this work is to make it easier for an organization to install and
 configure in an automated manner a secure, distributed environment for the
 deployment and operation of a microservices application. This automation lies
 in the correct configuration of our tool, which does not require any special
-knowledge on technical or security issues in regard to infrastructure and
+knowledge on technical or security issues concerning the infrastructure and
 operating systems.
 
 }
@@ -53,7 +53,7 @@ operating systems.
 \vskip 60pt
 
 \textenglish{
-\noindent \textbf{Keywords:} Cloud, Security, Virtualization, Virtual Machines, Containers, Container \mbox{Engine}, Micro-services, Automation, Hardening
+\noindent \textbf{Keywords:} Cloud, Security, Virtualization, Virtual Machines, Containers, Container Engine, Micro-services, Automation, Hardening
 }
 
 }
diff --git a/Bibliography.bib b/Bibliography.bib
index ecad874..4fd35ea 100644
--- a/Bibliography.bib
+++ b/Bibliography.bib
@@ -44,13 +44,6 @@
     urldate = {2023-04-07},
 }
 
-@online{LXC,
-    title = {What's LXC?},
-    author = {Linux Containers},
-    url = {https://linuxcontainers.org/lxc/introduction/},
-    urldate = {2023-02-02},
-}
-
 @online{LXCvsDocker,
     title = {LXC vs Docker: Which Container Platform Is Right for You?},
     author = {Eric Kahuha},
@@ -67,27 +60,6 @@
     urldate = {2023-08-07},
 }
 
-@online{dockerhub,
-    title = {Build and Ship any Application Anywhere},
-    author = {Docker},
-    url = {https://hub.docker.com/},
-    urldate = {2023-04-06},
-}
-
-@online{quay,
-    title = {Quay builds, analyzes, distributes your container images},
-    author = {Red Hat},
-    url = {https://quay.io/},
-    urldate = {2023-11-16},
-}
-
-@online{oci,
-    title = {Open Container Initiative},
-    author = {The Linux Foundation},
-    url = {https://opencontainers.org/},
-    urldate = {2023-04-08},
-}
-
 @online{LXCvsDocker2,
     title = {The Untold Story: Containers Before Docker's Rise - The LXC Revolution},
     author = {Dinesh Patil},
@@ -435,13 +407,6 @@
     urldate = {2023-12-10},
 }
 
-@online{gVisor,
-    title = {The Container Security Platform},
-    author = {Google},
-    url = {https://gvisor.dev/},
-    urldate = {2023-09-25},
-}
-
 @online{ibmVirtualizationDefinition,
     title = {What is virtualization?},
     author = {IBM},
@@ -618,20 +583,6 @@
     urldate = {2023-07-29},
 }
 
-@online{ansible,
-    title = {Ansible},
-    author = {Red Hat},
-    url = {https://www.ansible.com/},
-    urldate = {2023-11-23},
-}
-
-@online{terraform,
-    title = {Terraform},
-    author = {HashiCorp},
-    url = {https://www.terraform.io/},
-    urldate = {2023-09-19},
-}
-
 @article{mell2011nist,
     title = {The NIST Definition of Cloud Computing},
     author = {Peter Mell and Timothy Grance},
@@ -643,16 +594,6 @@
     urldate = {2023-11-12},
 }
 
-@online{AkihiroSuda,
-    author = {Akihiro Suda},
-    title = {rootlesskit},
-    year = {2020},
-    publisher = {GitHub},
-    journal = {GitHub repository},
-    url = {https://github.com/rootless-containers/rootlesskit},
-    urldate = {2023-07-18},
-}
-
 @inproceedings{reshetova2014security,
     title = {Security of OS-level virtualization technologies},
     author = {Reshetova, Elena and Karhunen, Janne and Nyman, Thomas and Asokan, N},
@@ -763,13 +704,6 @@
     urldate = {2023-10-29},
 }
 
-@online{apparmor,
-    title = {AppArmor},
-    author = {AppArmor},
-    url = {https://apparmor.net/},
-    urldate = {2023-02-06},
-}
-
 @online{selinux,
     title = {What is SELinux?},
     author = {Red Hat},
@@ -786,20 +720,6 @@
     urldate = {2023-07-11},
 }
 
-@online{vuls,
-    title = {Vuls},
-    author = {Kota Kanbe},
-    url = {https://vuls.io/},
-    urldate = {2023-12-05},
-}
-
-@online{vulsGithubPage,
-    title = {Vuls},
-    author = {future-architect},
-    url = {https://github.com/future-architect/vuls},
-    urldate = {2023-06-28},
-}
-
 @online{vulsArchitecture,
     title = {Vuls Architecture},
     author = {future-architect},
@@ -814,98 +734,6 @@
     urldate = {2023-12-05},
 }
 
-@online{lynis,
-    title = {Lynis},
-    author = {CISOfy},
-    url = {https://cisofy.com/lynis/},
-    urldate = {2023-12-06},
-}
-
-@online{lunar,
-    title = {Lunar},
-    author = {Lateral Blast},
-    url = {https://github.com/lateralblast/lunar},
-    urldate = {2023-12-06},
-}
-
-@online{vulsrepo,
-    title = {VulsRepo},
-    author = {ishiDACo},
-    url = {https://github.com/ishiDACo/vulsrepo},
-    urldate = {2023-12-06},
-}
-
-@online{awst3micro,
-    title = {Amazon EC2 T3 Instances},
-    author = {Amazon Web Services},
-    url = {https://aws.amazon.com/ec2/instance-types/t3/},
-    urldate = {2023-12-07},
-}
-
-@online{vantaget3micro,
-    title = {t3.micro},
-    author = {Vantage},
-    url = {https://instances.vantage.sh/aws/ec2/t3.micro},
-    urldate = {2023-12-07},
-}
-
-@online{watchtower,
-    title = {Watchtower},
-    author = {Containrrr},
-    url = {https://containrrr.dev/watchtower/},
-    urldate = {2023-11-10},
-}
-
-@online{secdep,
-    title = {SecDep},
-    author = {konsthol},
-    year = {2023},
-    url = {https://git.konsthol.eu/konsthol/SecDep},
-    urldate = {2023-09-28},
-}
-
-@online{pip,
-    title = {The Python package installer},
-    author = {pypa},
-    url = {https://github.com/pypa/pip},
-    urldate = {2023-08-12},
-}
-
-@online{libcloud,
-    title = {Apache Libcloud},
-    author = {The Apache Software Foundation},
-    url = {https://libcloud.apache.org/},
-    urldate = {2023-12-03},
-}
-
-@online{apache,
-    title = {Apache},
-    author = {The Apache Software Foundation},
-    url = {https://www.apache.org/},
-    urldate = {2023-08-07},
-}
-
-@online{jclouds,
-    title = {Apache jclouds},
-    author = {The Apache Software Foundation},
-    url = {https://jclouds.apache.org/},
-    urldate = {2023-07-26},
-}
-
-@online{java,
-    title = {Java},
-    author = {Oracle},
-    url = {https://www.java.com/en/},
-    urldate = {2023-09-15},
-}
-
-@online{python,
-    title = {Python},
-    author = {Python Software Foundation},
-    url = {https://www.python.org/},
-    urldate = {2023-04-12},
-}
-
 @online{libcloudProviders,
     title = {Apache Libcloud - Supported Providers},
     author = {The Apache Software Foundation},
@@ -913,137 +741,315 @@
     urldate = {2023-08-07},
 }
 
+@online{lynis,
+    title = {Lynis},
+    author = {CISOfy},
+    url = {https://cisofy.com/lynis/},
+}
+    urldate = {2023-12-06},
+
+@online{lunar,
+    title = {Lunar},
+    author = {Lateral Blast},
+    url = {https://github.com/lateralblast/lunar},
+}
+    urldate = {2023-12-06},
+
+@online{vulsrepo,
+    title = {VulsRepo},
+    author = {ishiDACo},
+    url = {https://github.com/ishiDACo/vulsrepo},
+}
+    urldate = {2023-12-06},
+
+@online{awst3micro,
+    title = {Amazon EC2 T3 Instances},
+    author = {Amazon Web Services},
+    url = {https://aws.amazon.com/ec2/instance-types/t3/},
+}
+    urldate = {2023-12-07},
+
+@online{vantaget3micro,
+    title = {t3.micro},
+    author = {Vantage},
+    url = {https://instances.vantage.sh/aws/ec2/t3.micro},
+}
+    urldate = {2023-12-07},
+
+@online{watchtower,
+    title = {Watchtower},
+    author = {Containrrr},
+    url = {https://containrrr.dev/watchtower/},
+}
+    urldate = {2023-11-10},
+
+@online{secdep,
+    title = {SecDep},
+    author = {konsthol},
+    year = {2023},
+    url = {https://git.konsthol.eu/konsthol/SecDep},
+}
+    urldate = {2023-09-28},
+
+@online{pip,
+    title = {The Python package installer},
+    author = {pypa},
+    url = {https://github.com/pypa/pip},
+}
+    urldate = {2023-08-12},
+
+@online{libcloud,
+    title = {Apache Libcloud},
+    author = {The Apache Software Foundation},
+    url = {https://libcloud.apache.org/},
+}
+    urldate = {2023-12-03},
+
+@online{apache,
+    title = {Apache},
+    author = {The Apache Software Foundation},
+    url = {https://www.apache.org/},
+}
+    urldate = {2023-08-07},
+
+@online{jclouds,
+    title = {Apache jclouds},
+    author = {The Apache Software Foundation},
+    url = {https://jclouds.apache.org/},
+}
+    urldate = {2023-07-26},
+
+@online{java,
+    title = {Java},
+    author = {Oracle},
+    url = {https://www.java.com/en/},
+}
+    urldate = {2023-09-15},
+
+@online{python,
+    title = {Python},
+    author = {Python Software Foundation},
+    url = {https://www.python.org/},
+}
+    urldate = {2023-04-12},
+
 @online{azure-mgmt-network,
     title = {Microsoft Azure SDK for Python},
     author = {Microsoft},
     url = {https://pypi.org/project/azure-mgmt-network/},
-    urldate = {2023-02-12},
 }
+    urldate = {2023-02-12},
 
 @online{azure-mgmt-resource,
     title = {Microsoft Azure SDK for Python},
     author = {Microsoft},
     url = {https://pypi.org/project/azure-mgmt-resource/},
-    urldate = {2023-05-21},
 }
+    urldate = {2023-05-21},
 
 @online{yuml,
     title = {yUML},
     author = {yUML},
     url = {https://yuml.me/},
-    urldate = {2023-12-30},
 }
+    urldate = {2023-12-30},
 
 @online{libcloud-cli,
     title = {libcloud-cli},
     author = {Terradue},
     url = {https://github.com/Terradue/libcloud-cli},
-    urldate = {2023-08-31},
 }
+    urldate = {2023-08-31},
 
 @online{jshielder,
     title = {JShielder},
     author = {Jsitech},
     url = {https://github.com/Jsitech/JShielder},
-    urldate = {2023-12-05},
 }
+    urldate = {2023-12-05},
 
 @online{nixarmor,
     title = {nixarmor},
     author = {Emir Ozer},
     url = {https://github.com/emirozer/nixarmor},
-    urldate = {2023-12-05},
 }
+    urldate = {2023-12-05},
 
 @online{ubuntu,
     title = {Ubuntu},
     author = {Canonical},
     url = {https://ubuntu.com/},
-    urldate = {2023-12-30},
 }
+    urldate = {2023-12-30},
 
 @online{debian,
     title = {Debian},
     author = {Debian},
     url = {https://www.debian.org/},
-    urldate = {2023-12-30},
 }
+    urldate = {2023-12-30},
 
 @online{centos,
     title = {CentOS},
     author = {CentOS},
     url = {https://www.centos.org/},
-    urldate = {2023-12-30},
 }
+    urldate = {2023-12-30},
 
 @online{fedora,
     title = {Fedora},
     author = {Fedora},
     url = {https://fedoraproject.org/},
-    urldate = {2023-12-30},
 }
+    urldate = {2023-12-30},
 
 @online{redhat,
     title = {Red Hat},
     author = {Red Hat},
     url = {https://www.redhat.com/},
-    urldate = {2023-12-30},
 }
+    urldate = {2023-12-30},
 
 @online{opensuse,
     title = {openSUSE},
     author = {openSUSE},
     url = {https://www.opensuse.org/},
-    urldate = {2023-12-30},
 }
+    urldate = {2023-12-30},
 
 @online{mermaid,
     title = {Mermaid},
     author = {Mermaid},
     url = {https://mermaid.live/},
-    urldate = {2024-01-05},
 }
+    urldate = {2024-01-05},
 
 @online{code2flow,
     title = {code2flow},
     author = {Scott Rogowski},
     url = {https://github.com/scottrogowski/code2flow},
-    urldate = {2024-01-05},
 }
+    urldate = {2024-01-05},
 
 @online{callGraph,
     title = {callGraph},
     author = {Chris Koknat},
     url = {https://github.com/koknat/callGraph},
-    urldate = {2024-01-05},
 }
+    urldate = {2024-01-05},
 
 @online{pydeps,
     title = {pydeps},
     author = {Bjorn},
     url = {https://github.com/thebjorn/pydeps},
-    urldate = {2024-01-05},
 }
+    urldate = {2024-01-05},
 
 @online{doxygen,
     title = {Doxygen},
     author = {Dimitri van Heesch},
     url = {https://github.com/doxygen/doxygen},
-    urldate = {2024-01-05},
 }
+    urldate = {2024-01-05},
 
 @online{mysql,
     title = {MySQL},
     author = {Oracle},
     url = {https://www.mysql.com/},
-    urldate = {2024-01-05},
 }
+    urldate = {2024-01-05},
 
 @online{nginx,
     title = {NGINX},
     author = {NGINX},
     url = {https://nginx.org/en/},
+}
     urldate = {2024-01-05},
+
+@online{LXC,
+    title = {What's LXC?},
+    author = {Linux Containers},
+    url = {https://linuxcontainers.org/lxc/introduction/},
+}
+    urldate = {2023-02-02},
+
+@online{dockerhub,
+    title = {Build and Ship any Application Anywhere},
+    author = {Docker},
+    url = {https://hub.docker.com/},
+}
+    urldate = {2023-04-06},
+
+@online{quay,
+    title = {Quay builds, analyzes, distributes your container images},
+    author = {Red Hat},
+    url = {https://quay.io/},
+}
+    urldate = {2023-11-16},
+
+@online{oci,
+    title = {Open Container Initiative},
+    author = {The Linux Foundation},
+    url = {https://opencontainers.org/},
+}
+    urldate = {2023-04-08},
+
+@online{gVisor,
+    title = {The Container Security Platform},
+    author = {Google},
+    url = {https://gvisor.dev/},
+}
+    urldate = {2023-09-25},
+
+@online{ansible,
+    title = {Ansible},
+    author = {Red Hat},
+    url = {https://www.ansible.com/},
+}
+    urldate = {2023-11-23},
+
+@online{terraform,
+    title = {Terraform},
+    author = {HashiCorp},
+    url = {https://www.terraform.io/},
+}
+    urldate = {2023-09-19},
+
+@online{AkihiroSuda,
+    author = {Akihiro Suda},
+    title = {rootlesskit},
+    year = {2020},
+    publisher = {GitHub},
+    journal = {GitHub repository},
+    url = {https://github.com/rootless-containers/rootlesskit},
+}
+    urldate = {2023-07-18},
+
+@online{apparmor,
+    title = {AppArmor},
+    author = {AppArmor},
+    url = {https://apparmor.net/},
+}
+    urldate = {2023-02-06},
+
+@online{vuls,
+    title = {Vuls},
+    author = {Kota Kanbe},
+    url = {https://vuls.io/},
+}
+    urldate = {2023-12-05},
+
+@online{vulsGithubPage,
+    title = {Vuls},
+    author = {future-architect},
+    url = {https://github.com/future-architect/vuls},
+}
+    urldate = {2023-06-28},
+
+@online{rkt,
+    title = {rkt},
+    author = {rkt},
+    url = {https://github.com/rkt/rkt},
 }
 
 inproceedings{manu2016study,
diff --git a/Chapters/1.Introduction.tex b/Chapters/1.Introduction.tex
index 9eb9e7f..558b21e 100644
--- a/Chapters/1.Introduction.tex
+++ b/Chapters/1.Introduction.tex
@@ -4,14 +4,14 @@
 
 \noindent Παραδοσιακά, όταν ένας χρήστης/εταιρεία επιθυμούσε να διαθέτει μια
 υπηρεσία στο ευρύ κοινό θα έπρεπε να επενδύσει ένα κατάλληλο κεφάλαιο για την
-αγορά εξοπλισμού. Σε περίπτωση που η υπηρεσία αυτή τύγχανε ευρείας αποδοχής,
-καθίστατο επιτακτική η ανάγκη της επέκτασης του υφιστάμενου εξοπλισμού αλλά και
-της εγκατάστασης όλων των αναγκαίων πόρων λογισμικού (βάσεων δεδομένων
-(Databases), λογισμικό της υπηρεσίας, αρχείων ρυθμίσεων, κ.λπ.) στα νέα
-κομμάτια εξοπλισμού που αγοράσθηκαν. Η παραπάνω διαδικασία απαιτούσε επιπλέον
-κεφάλαιο και αρκετές εργατοώρες προκειμένου να γίνει πράξη. Επιπρόσθετα, η
-λειτουργία του εξοπλισμού και η συντήρησή του είχε κι αυτή ένα σημαντικό
-κόστος.
+αγορά σχετικού εξοπλισμού. Σε περίπτωση που η υπηρεσία αυτή τύγχανε ευρείας
+αποδοχής, καθίστατο επιτακτική η ανάγκη της επέκτασης του υφιστάμενου
+εξοπλισμού αλλά και της εγκατάστασης όλων των αναγκαίων πόρων λογισμικού
+(βάσεων δεδομένων (Databases), λογισμικό της υπηρεσίας, αρχείων ρυθμίσεων,
+κ.λπ.) στα νέα κομμάτια εξοπλισμού που αγοράσθηκαν. Η παραπάνω διαδικασία
+απαιτούσε επιπλέον κεφάλαιο και αρκετές εργατοώρες προκειμένου να γίνει πράξη.
+Επιπρόσθετα, η λειτουργία του εξοπλισμού και η συντήρησή του είχε κι αυτή ένα
+σημαντικό κόστος.
 
 Στις αρχές του 2000 ο τρόπος διεξαγωγής της παραπάνω διαδικασίας άλλαξε ριζικά
 όταν η Amazon, ψάχνοντας τρόπους να κλιμακώσει τις υπηρεσίες που προσέφερε στον
@@ -36,22 +36,23 @@ AWS (Amazon Web Services). Η AWS άρχισε να προσφέρει υπηρ
 προσφέρουν υπηρεσίες νεφο-υπολογιστικής και μάλιστα μερικές από αυτές, όπως η
 Linode, Vultr και Digital Ocean, προσφέρουν ως την κύρια υπηρεσία τους τη
 δυνατότητα διάθεσης υπολογιστικών πόρων στους χρήστες με τη μορφή ενοικίασης
-εικονικών μηχανών (Virtual Machines).
+εικονικών μηχανών (Virtual Machines - VMs).
 
 \section{Ασφάλεια Περιβαλλόντων Νέφους} \label{cloudComputingSecurity}
 
 Η ασφάλεια των περιβαλλόντων νέφους είναι ένα θέμα που απασχολεί πολύ τους
 χρήστες και ακόμα περισσότερο τις επιχειρήσεις που βασίζονται σε υπηρεσίες
-νεφο-υπολογιστικής για την διάθεση των δικών τους υπηρεσιών. Η επίτευξή της
-εξαρτάται από τρεις βασικούς παράγοντες. Ο πρώτος είναι η ασφάλεια των υποδομών
-νέφους, όπου στην περίπτωση χρήσης υπηρεσιών IaaS υπεύθυνος είναι ο πάροχος
-νέφους. Ο δεύτερος παράγοντας είναι η ασφάλεια των τεχνολογιών εικονικοποίησης
-που χρησιμοποιούνται, όπου υπεύθυνος είναι εν μέρει ο πάροχος για τις
-τεχνολογίες που επέλεξε προκειμένου να διαθέσει τους απομακρυσμένους
-(εικονικούς) διακομιστές του και ο τελικός χρήστης εφόσον προβεί στην χρήση
-δοχείων. Ο τρίτος και τελευταίος παράγοντας είναι οι ενέργειες στις οποίες
-οφείλει να προβεί ο χρήστης προκειμένου να διατηρήσει ή να ενισχύσει την
-ασφάλεια της υπηρεσίας του (που θα φιλοξενείται από μια υποδομή νέφους) σύμφωνα
+νεφο-υπολογιστικής για την διάθεση των δικών τους υπηρεσιών. Η επίτευξη
+κατάλληλου επιπέδου ασφάλειας εξαρτάται από τρεις βασικούς παράγοντες. Ο πρώτος
+είναι η ασφάλεια των υποδομών νέφους, όπου στην περίπτωση χρήσης υπηρεσιών IaaS
+υπεύθυνος είναι ο πάροχος νέφους. Ο δεύτερος παράγοντας είναι η ασφάλεια των
+τεχνολογιών εικονικοποίησης που χρησιμοποιούνται, όπου υπεύθυνος είναι εν μέρει
+ο πάροχος για τις τεχνολογίες που επέλεξε προκειμένου να διαθέσει τους
+απομακρυσμένους (εικονικούς) διακομιστές του και ο τελικός χρήστης εφόσον
+προβεί στην χρήση τεχνολογιών δοχείων (containers) (δηλ. ένα είδος τεχνολογίας
+εικονικοποίησης). Ο τρίτος και τελευταίος παράγοντας είναι οι ενέργειες στις
+οποίες οφείλει να προβεί ο χρήστης προκειμένου να διατηρήσει ή να ενισχύσει την
+ασφάλεια της υπηρεσίας του (που θα φιλοξενείται σε μια υποδομή νέφους) σύμφωνα
 με τις ανάγκες του.
 
 Όταν επιλέξει ένας χρήστης να δημιουργήσει εικονικές μηχανές μέσω μιας από τις
@@ -60,7 +61,7 @@ Linode, Vultr και Digital Ocean, προσφέρουν ως την κύρια
 προσφέρονται, τις περισσότερες φορές διατίθενται διάφορες διανομές λειτουργικού
 συστήματος Linux, οι οποίες ενδέχεται να έχουν εγκατεστημένα και ρυθμισμένα εκ
 των προτέρων διάφορα λογισμικά, όπως το σύστημα διαχείρισης βάσεων δεδομένων
-MySQL \footfullcite{mysql} και το διακομιστή ιστού Nginx \footfullcite{nginx}.
+MySQL \footfullcite{mysql} και ο διακομιστής ιστού nginx \footfullcite{nginx}.
 Με αυτό τον τρόπο, η διαδικασία δημιουργίας εικονικής μηχανής είναι αρκετά
 εύκολη για τον χρήστη, ο οποίος δεν χρειάζεται να έχει ειδικές γνώσεις στο
 υλικό για να το πετύχει αυτό. Στην προκειμένη περίπτωση, ενώ υπάρχει μηδενική
@@ -76,7 +77,7 @@ MySQL \footfullcite{mysql} και το διακομιστή ιστού Nginx \fo
 
 Όπως αναφέρεται και στο \citealt{balduzzi2012security}, υπάρχουν υπηρεσίες IaaS
 που προσφέρουν διανομές λειτουργικού συστήματος Linux με εγκατεστημένα και
-ρυθμισμένα εκ τω προτέρων προγράμματα από τρίτους. Σε ορισμένες περιπτώσεις
+ρυθμισμένα εκ των προτέρων προγράμματα από τρίτους. Σε ορισμένες περιπτώσεις
 όπου υπάρχει τυφλή εμπιστοσύνη προς την ορθότητα των ρυθμίσεων αυτών σε
 συνδυασμό με έλλειψη γνώσης των εργαλείων, ενδέχεται λόγω ανθρώπινου λάθους ή
 στοχευμένα, να μένει ο τελικός χρήστης ευάλωτος σε ρίσκα ασφαλείας, όπως μη
@@ -85,9 +86,10 @@ MySQL \footfullcite{mysql} και το διακομιστή ιστού Nginx \fo
 παραλείψει να εφαρμόσει τις απαραίτητες ενημερώσεις ασφαλείας στις τεχνολογίες
 εικονικοποίησης που χρησιμοποιεί, είναι πιθανό κάποιο από τα προγράμματα αυτά
 να μπορέσει να πραγματοποιήσει μια επίθεση hyperjacking \cite{Hyperjacking} και
-να αποκτήσει έλεγχο του υπερ-επόπτη με αποτέλεσμα να είναι σε θέση να
-προκαλέσει ζημιές είτε σε διαφορετικές εικονικές μηχανές είτε στον (φυσικό)
-διακομιστή στον οποίο εκτελείται.
+να αποκτήσει έλεγχο του υπερ-επόπτη (hypervisor) με αποτέλεσμα να είναι σε θέση
+να προκαλέσει ζημιές είτε σε διαφορετικές εικονικές μηχανές που ελέγχονται από
+τον υπερ-επόπτη είτε στον (φυσικό) διακομιστή (host machine ή απλώς host) στον
+οποίο αυτός εκτελείται.
 
 \section{Εικονικοποίηση και τεχνολογίες υλοποίησής της} \label{virtualizationTechnologiesIntroduction}
 
@@ -99,36 +101,31 @@ MySQL \footfullcite{mysql} και το διακομιστή ιστού Nginx \fo
 \ref{virtualizationImplementations} αλλά οι δύο βασικότερες υλοποιήσεις της
 είναι η εικονικοποίηση διακομιστών και λειτουργικών συστημάτων (δοχειοποίηση).
 
-Στην εικονικοποίηση διακομιστών, ένας φυσικός διακομιστής χωρίζει με την
-βοήθεια ενός υπερ-επόπτη τους πόρους του, όπως η μνήμη, ο αποθηκευτικός χώρος
-και ο επεξεργαστής του, σε πολλά μικρότερα εικονικά μηχανήματα. Κάθε εικονικό
-μηχάνημα μπορεί να εκτελεί διαφορετικό λειτουργικό σύστημα και να έχει
-διαφορετικές ρυθμίσεις από τα υπόλοιπα. Η διάθεση ενός εικονικού μηχανήματος
-δεν περιορίζεται μονάχα σε τοπικούς υπολογιστές και έτσι πολλές φορές
-συνηθίζεται η ενοικίαση τέτοιων μηχανημάτων προκειμένου να μπορέσουν να
-χρησιμοποιηθούν από τρίτα πρόσωπα για την επίτευξη των δικών τους διεργασιών.
+Στην εικονικοποίηση διακομιστών (host virtualization), ένας φυσικός διακομιστής
+χωρίζει με την βοήθεια ενός υπερ-επόπτη τους πόρους του, όπως είναι η μνήμη, ο
+αποθηκευτικός χώρος και ο επεξεργαστής του, σε πολλές μικρότερες εικονικές
+μηχανές. Κάθε εικονική μηχανή μπορεί να εκτελεί διαφορετικό λειτουργικό σύστημα
+και να έχει διαφορετικές ρυθμίσεις από τις υπόλοιπες. Η διάθεση μιας εικονικής
+μηχανής δεν περιορίζεται μονάχα σε τοπικούς υπολογιστές και έτσι πολλές φορές
+συνηθίζεται η ενοικίαση τέτοιων μηχανών (σε περιβάλλοντα νέφους) προκειμένου να
+μπορέσουν να χρησιμοποιηθούν από τρίτα πρόσωπα για την επίτευξη των δικών τους
+διαδικασιών.
 
-Η δοχειοποίηση αποτελεί μια ειδική περίπτωση εικονικοποίησης όπου αντί για το
-υλικό, εικονικοποιείται το λειτουργικό σύστημα. Αυτό, καθιστά την δοχειοποίηση
-πιο αποδοτική από την εικονικοποίηση διακομιστών, καθώς δεν χρειάζεται να
-εκτελεστεί ένας υπερ-επόπτης για την διαχείριση υπολογιστικών πόρων. Επιπλέον,
-η δοχειοποίηση επιτρέπει την εκτέλεση περισσότερων εικονικών περιβαλλόντων στον
-ίδιο φυσικό διακομιστή και έτσι, η απόδοση του υλικού αυξάνεται ακόμα
-περισσότερο. Συνήθως χρησιμοποιείται για την διάθεση προγραμμάτων στο ευρύ
-κοινό, τα οποία ακολουθούν την αρχιτεκτονική μικρο-υπηρεσιών (microservices)
-και λόγω του ότι τα παράγωγά της περιέχουν όλες τις απαραίτητες βιβλιοθήκες για
-την εκτέλεσή τους, χωρίς να βασίζονται στο υποκείμενο νέφος στο οποίο
-στεγάζονται, αποτελούν αρκετά δημοφιλή επιλογή τεχνολογίας διάθεσης υπηρεσιών.
-
-Τα δοχεία είναι ένα προϊόν της δοχειοποίησης και αποτελούν το αποτέλεσμα της
-εικονικοποίησης σε επίπεδο λειτουργικού συστήματος. Με την βοήθεια του
-λειτουργικού συστήματος, δημιουργούνται εικονικά περιβάλλοντα στα οποία μπορούν
-αυτά να εκτελεστούν. Ουσιαστικά, μια μηχανή δοχείων αιτείται από το λειτουργικό
-σύστημα την διάθεση ενός εικονικού περιβάλλοντος για την εκτέλεση των
-διεργασιών ενός προγράμματος. Το πρόγραμμα αυτό, καθώς και όλες οι βιβλιοθήκες
-που χρειάζεται, καθορίζονται σε μια εικόνα δοχείου (container image) την οποία
-η μηχανή δοχείων θα πρέπει να ανακτήσει, να αποθηκεύσει και με βάση αυτήν να
-δημιουργήσει το αντιστοιχούμενο δοχείο που αυτή περιγράφει.
+Κατά την δοχειοποίηση (containerization), μιας ειδικής περίπτωσης
+εικονικοποίησης, αντί για το υλικό, εικονικοποιείται το λειτουργικό σύστημα.
+Επομένως, τα δοχεία είναι ένα προϊόν της δοχειοποίησης και αποτελούν το
+αποτέλεσμα της εικονικοποίησης σε επίπεδο λειτουργικού συστήματος. Με την
+βοήθεια του λειτουργικού συστήματος, δημιουργούνται εικονικά περιβάλλοντα στα
+οποία μπορούν αυτά να εκτελεστούν. Ουσιαστικά, μια μηχανή δοχείων αιτείται από
+το λειτουργικό σύστημα την διάθεση ενός εικονικού περιβάλλοντος για την
+εκτέλεση των διεργασιών ενός προγράμματος. Το πρόγραμμα αυτό, καθώς και όλες οι
+βιβλιοθήκες που χρειάζεται, καθορίζονται σε μια εικόνα δοχείου (container
+image), την οποία η μηχανή δοχείων θα πρέπει να ανακτήσει, να αποθηκεύσει και
+με βάση αυτήν να δημιουργήσει το αντιστοιχούμενο δοχείο που αυτή περιγράφει. Η
+πιο συνηθισμένη υλοποίηση της δοχειοποίησης είναι η δοχειοποίηση εφαρμογών μέσω
+της μηχανής δοχείων Docker. Αυτό συμβαίνει διότι μέσω της πλατφόρμας που αυτό
+παρέχει, η διαχείριση και χρήση δοχείων επιτυγχάνεται εύκολα από ομάδες
+ανάπτυξης λογισμικού κάθε επιπέδου.
 
 Η δοχειοποίηση αποτελεί μια ελαφρύτερη εναλλακτική λύση σε σύγκριση με την
 εικονικοποίηση και είθισται να προτιμάται για την ανάπτυξη και διάθεση
@@ -136,251 +133,19 @@ MySQL \footfullcite{mysql} και το διακομιστή ιστού Nginx \fo
 δοχείων μπορεί να πραγματοποιηθεί σε κάθε περιβάλλον και νέφος, καθώς και στο
 γεγονός ότι αυτά απαιτούν λιγότερους πόρους σε σχέση με τις εικονικές μηχανές,
 αφού οι υποκείμενοι πόροι του συστήματος μπορούν να μοιραστούν μεταξύ των
-διαφορετικών δοχείων.
+διαφορετικών δοχείων. Αυτό, καθιστά την δοχειοποίηση πιο αποδοτική από την
+εικονικοποίηση διακομιστών, καθώς δεν χρειάζεται να εκτελεστεί ένας
+υπερ-επόπτης για την διαχείριση υπολογιστικών πόρων. Επιπλέον, η δοχειοποίηση
+επιτρέπει την εκτέλεση περισσότερων εικονικών περιβαλλόντων στον ίδιο φυσικό
+διακομιστή και έτσι, η απόδοση του υλικού αυξάνεται ακόμα περισσότερο. Συνήθως
+χρησιμοποιείται για την διάθεση εφαρμογών στο ευρύ κοινό, οι οποίες ακολουθούν
+την αρχιτεκτονική μικρο-υπηρεσιών (microservices). Δηλαδή, της διαμέρισης των
+λειτουργιών τους σε δοχεία. Λόγω του ότι τα παράγωγα της δοχειοποίησης
+περιέχουν όλες τις απαραίτητες βιβλιοθήκες για την εκτέλεσή τους, χωρίς να
+βασίζονται στο υποκείμενο νέφος στο οποίο στεγάζονται, η δοχειοποίηση αποτελεί
+αρκετά δημοφιλή επιλογή τεχνολογίας διάθεσης υπηρεσιών.
 
-\subsection{Πλεονεκτήματα δοχείων έναντι εικονικών μηχανών} \label{containerAdvantages}
-
-Ενώ μια εικονική μηχανή είναι μια πλήρης αναπαράσταση ενός φυσικού διακομιστή,
-ένα δοχείο εξομοιώνει μονάχα το περιβάλλον εκτέλεσης ενός λογισμικού. Αυτό
-σημαίνει πως εάν θεωρηθεί ως τελικός στόχος η εκτέλεση ενός λογισμικού
-απομονωμένο από το υπόλοιπο σύστημα, αυτό επιτυγχάνεται με δύο διαφορετικούς
-τρόπους, αφού οι εικονικές μηχανές και τα δοχεία χρησιμοποιούν διαφορετικού
-είδους εικονικοποίηση. Στην περίπτωση των δοχείων δεν έχουμε απομόνωση μηχανών
-αλλά διεργασιών. Γεγονός που συμβάλλει στην αποφυγή της επιβάρυνσης του
-συστήματος που θα επιβάλλονταν από τις διεργασίες του υπερ-επόπτη και της
-καθυστέρησης που θα υπήρχε για την εκκίνηση ενός ολόκληρου λειτουργικού
-συστήματος. Επιπλέον, η μη χρήση τεχνολογιών εικονικοποίησης σε επίπεδο υλικού
-αυξάνει την μεταφερσιμότητα των δοχείων αφού σε μια εικόνα δοχείου μπορούν να
-ορισθούν όλες οι απαραίτητες εξαρτήσεις ενός λογισμικού και να αναδημιουργηθούν
-σε οποιοδήποτε περιβάλλον νέφους.
-
-Παρ' όλο που πολλές φορές τα δοχεία συγχέονται με τις εικονικές μηχανές, οι δύο
-αυτές έννοιες έχουν αρκετές διαφορές στην αρχιτεκτονική τους. Στην παραδοσιακή
-εικονικοποίηση είτε αυτή γίνεται στις υπάρχουσες υποδομές μιας επιχείρησης είτε
-σε ένα περιβάλλον νέφους, ένας υπερ-επόπτης πρέπει να χρησιμοποιηθεί για να
-εικονικοποιήσει φυσικό υλικό. Κάθε εικονική μηχανή έχει ένα δικό της
-λειτουργικό σύστημα και ένα εικονικό αντίγραφο του υλικού που απαιτεί για να
-εκτελεστεί μαζί με μια εφαρμογή, τις βιβλιοθήκες και τις εξαρτήσεις της. Από
-την άλλη, ένα δοχείο αντί να εικονικοποιήσει το υλικό, εικονικοποιεί το
-λειτουργικό σύστημα ούτως ώστε κάθε δοχείο να περιέχει μόνο την εφαρμογή, τις
-βιβλιοθήκες και τις εξαρτήσεις της \cite{ibmContainerVsVm}.
-
-\noindent Το Σχήμα \ref{fig:containerVsVm} παρουσιάζει τις διαφορές ανάμεσα
-στην αρχιτεκτονική της εικονικοποίησης και των δοχείων.
-
-\begin{center}
-\begin{figure}[!ht]
-\centering
-    \includegraphics[width = \textwidth]{Figures/RedHat_Virtualization/virtualization-vs-containers_transparent.png}
-    \captionof{figure}{Χρήση εικονικοποίησης έναντι δοχείων \cite{redhatVirtualizationDefinition}}
-    \label{fig:containerVsVm}
-\end{figure}
-\vspace*{-30pt}
-\end{center}
-
-Η απουσία του εικονικού λειτουργικού υλικού είναι που καθιστά τα δοχεία
-γρήγορα, φορητά και μικρότερα σε μέγεθος. Για να γίνει πιο εμφανής η διαφορά,
-σύμφωνα με τη Red Hat \cite{redhatContainerVsVm}, το μέγεθος των εικονικών
-μηχανών είναι της τάξεως των gigabyte ενώ των δοχείων είναι της τάξεως των
-megabyte. Πολλές φορές, όπως αναφέρεται και σε μια δημοσίευση
-\cite{ibmContainerVsVm} της \citeauthor{ibmContainerVsVm}, τα δοχεία
-χρησιμοποιούνται για εφαρμογές αρχιτεκτονικής μικρο-υπηρεσιών (microservices),
-όπου κάθε ξεχωριστό κομμάτι (δηλ. μικρο-υπηρεσία) αντιπροσωπεύει ένα συστατικό
-της εφαρμογής που παίρνει την μορφή ενός δοχείου. Με αυτόν τον τρόπο, είναι
-ευκολότερη η κλιμάκωση μιας εφαρμογής απ' ότι θα ήταν με μια μονολιθική
-αρχιτεκτονική. Αυτό συμβαίνει διότι μπορεί να κλιμακώνεται μόνο το μέρος ή τα
-μέρη της που έχουν αύξηση του φόρτου εργασίας τους, μέσω της χρήσης
-περισσότερων δοχείων που αντιστοιχούν σε αυτά τα μέρη/μικρο-υπηρεσίες.
-Αντιθέτως, η κλιμάκωση μιας μονολιθικής εφαρμογής θα απαιτούσε την δημιουργία
-πολλαπλών δοχείων μεγάλου μεγέθους ή πολλαπλών εικονικών μηχανών, οδηγώντας σε
-μεγάλη και αχρείαστη σπατάλη πόρων. Λόγω του γεγονότος πως μια εφαρμογή
-αποτελείται από πολλαπλές μικρο-υπηρεσίες, οι οποίες μπορεί να έχουν πολλαπλά
-στιγμιότυπα (δηλ. μεγάλο αριθμό δοχείων) ανά πάσα χρονική στιγμή, απαιτείται η
-χρήση μιας πλατφόρμας ενορχήστρωσης δοχείων για την αυτοματοποίηση της
-εγκατάστασης, εκτέλεσης και κλιμάκωσης της εφαρμογής κατά μήκος πολλαπλών πόρων
-(δηλ. εικονικών ή φυσικών μηχανών), όπως είναι το Kubernetes ή το Docker Swarm.
-Από την άλλη, αν είναι επιθυμητή η ενορχήστρωση των δοχείων μιας εφαρμογής σε
-έναν πόρο (φυσικό ή εικονικό μηχάνημα), τότε είναι δυνατή η χρήση εργαλείων
-όπως το Docker Compose.
-
-Το μόνο μειονέκτημα της τεχνολογίας των δοχείων, το οποίο δεν επηρεάζει κατά
-πολύ τη χρήση τους, είναι το γεγονός ότι δοχεία που δημιουργήθηκαν για να
-εκτελούν προγράμματα που απαιτούν την ύπαρξη του λειτουργικού συστήματος
-Windows δε μπορούν να εκτελεστούν σε ένα περιβάλλον με τον πυρήνα του Linux και
-το ίδιο ισχύει και αντιστρόφως \cite{containerOSlimitations}.
-
-Εν γένει, τα βασικότερα πλεονεκτήματα των δοχείων σε σχέση με τις εικονικές
-μηχανές είναι ο διαμοιρασμός του πυρήνα του λειτουργικού συστήματος φιλοξενίας
-και η μεταφερσιμότητά τους. Το γεγονός ότι μοιράζονται τον ίδιο πυρήνα έχει ως
-αποτέλεσμα να μην χρειάζεται να απονεμηθούν πόροι για εικονικοποίηση μηχανών με
-σκοπό την στέγαση ενός ολόκληρου ξεχωριστού λειτουργικού συστήματος (όπως
-γίνεται στις εικονικές μηχανές). Επιπλέον, τα δοχεία μπορούν να εκτελεστούν σε
-οποιοδήποτε περιβάλλον είναι ήδη εγκατεστημένη μια μηχανή δοχείων (όπως το
-Docker) όπου μάλιστα η ταχύτητα δημιουργίας τους είναι πολύ πιο γρήγορη σε
-σχέση με αυτή των εικονικών μηχανών λόγω του μικρού μεγέθους και των ελάχιστων
-μη λειτουργικών απαιτήσεών τους.
-
-\subsection{Εργαλεία διαχείρισης δοχείων και έλευση του Docker} \label{containerManagement}
-
-Στις μέρες μας, η δημοτικότητα του Docker έχει συνταυτίσει τους όρους Docker
-και Container (δοχείο) αν και είναι διαφορετικοί. Παρ' όλα αυτά, η ιδέα της
-δημιουργίας απομονωμένων περιβαλλόντων εκτέλεσης λογισμικού υπήρχε προτού βγει
-το Docker στην αγορά. Ιστορικά, οι πρώτες τεχνολογίες περί δοχείων έκαναν την
-είσοδό τους από το 1979, όταν εισήχθη το chroot \cite{chrootCommand} στην
-έβδομη έκδοση του Unix \cite{containerHistory}. Πρόκειται για μια εντολή που
-περιορίζει την πρόσβαση αρχείων που διαθέτει μια εφαρμογή, σε ένα συγκεκριμένο
-φάκελο, ο οποίος ορίζεται ως ο καινούριος αρχικός (root). Ο κύριος σκοπός του
-chroot ήταν η ενίσχυση της ασφάλειας ούτως ώστε στην περίπτωση εκμετάλλευσης
-μιας εσωτερικής ευπάθειας της εφαρμογής, να παραμένουν ανεπηρέαστα τα μέρη του
-συστήματος εκτός του φακέλου στον οποίο είχε πρόσβαση. Εκείνη την εποχή αυτό
-ήταν αρκετό, αλλά οι απαιτήσεις ασφαλείας με τον καιρό αυξάνονταν και υπήρχε η
-ανάγκη διαφορετικών μεθόδων απομόνωσης μιας και από κατασκευής του, το chroot
-δεν περιόριζε έναν χρήστη ή μια διεργασία με διαχειριστικά δικαιώματα
-\cite{chrootRestrictions}. Μερικά χρόνια αργότερα, το 2004 δημιουργήθηκαν και
-ενσωματώθηκαν στον πυρήνα του Linux οι ομάδες ελέγχου, με την βοήθεια των
-οποίων ήταν πλέον δυνατή η απομόνωση πόρων του συστήματος σε ένα υποσύνολο
-διεργασιών.
-
-Αυτές οι τεχνολογίες σήμαναν της έναρξη της ιδέας της δοχειοποίησης και έτσι το
-2008 ήρθε στο προσκήνιο το LXC (Linux Container Technology) \footfullcite{LXC}.
-Το πρώτο εργαλείο που χρησιμοποιούσε τεχνολογίες δοχείων για την δημιουργία και
-εκτέλεση πολλαπλών λειτουργικών συστημάτων Linux στο ίδιο μηχάνημα.
-Χρησιμοποιώντας μηχανισμούς που προσέφερε το λειτουργικό σύστημα, επέτρεπε
-πλήρη εικονικοποίηση ενός στιγμιότυπου Linux σε μορφή δοχείου και παρείχε
-αρκετές λειτουργίες όπως η δημιουργία, η εκκίνηση και η διαγραφή LXC δοχείων.
-Παρ' όλα αυτά, επικεντρωνόταν στην δοχειοποίηση λειτουργικών συστημάτων και όχι
-εφαρμογών \cite{LXCvsDocker}, καθιστώντας δύσκολη και περίπλοκη την χρήση του
-όταν η κύρια ανάγκη ήταν η απομόνωση εφαρμογών.
-
-Ενώ λοιπόν προϋπήρχαν εργαλεία διαχείρισης δοχείων, τα οποία χρησιμοποιούνται
-ακόμα και στις μέρες μας, λόγω του συνδυασμού της δυσκολίας στην χρήση τους και
-του εξειδικευμένου σκοπού ύπαρξής τους δεν είχαν υιοθετηθεί αρκετά. Όλα τα
-παραπάνω οδήγησαν στην δημιουργία του Docker το 2013, με την έλευση του οποίου
-η τεχνολογία των δοχείων εκτοξεύτηκε. Το Docker είναι ένα σύνολο προϊόντων PaaS
-(Platform-as-a-Service) (Πλατφόρμα ως Υπηρεσία) και παρέχει μια πλατφόρμα με
-μηχανισμούς για συναρμολόγηση, θέση σε λειτουργία, εκτέλεση, ενημέρωση και
-διαχείριση προγραμμάτων σε μορφή δοχείων. Σε αντίθεση με το LXC, αποτελεί μια
-μηχανή δοχείων υψηλού επιπέδου με κύριο στόχο την δοχειοποίηση εφαρμογών. Εκτός
-από τον διαχωρισμό ανάμεσα στον πηγαίο κώδικα, τις βιβλιοθήκες και εξαρτήσεις
-ενός λογισμικού από το κύριο σύστημα (φιλοξενίας), παρέχει και δυνατότητες
-επικοινωνίας με αποθετήρια εικόνων δοχείωv, όπως είναι το Docker Hub
-\footfullcite{dockerhub}, το επίσημο αποθετήριο του Docker, το Quay
-\footfullcite{quay}, ένα εναλλακτικό αποθετήριο της Red Hat ή οποιοδήποτε άλλο
-αποθετήριο συμβατό με τις προδιαγραφές που έχει ορίσει η OCI (Open Container
-Initiative) \footfullcite{oci}. Μέσω τέτοιων υπηρεσιών, οι χρήστες έχουν
-πρόσβαση και διαμοιράζονται χιλιάδες εικόνες δοχείων που τους επιτρέπουν να
-ολοκληρώσουν διάφορα μέρη μιας υπάρχουσας ή νέας εφαρμογής. Επιπλέον, όντας μια
-μηχανή δοχείων υψηλού επιπέδου όλες οι λειτουργίες που θα απαιτούσαν
-εξειδικευμένες γνώσεις προκειμένου να πραγματοποιηθούν, έχουν συμπυκνωθεί σε
-απλές εντολές, καθιστώντας έτσι εύκολη την χρήση του για προγραμματιστές κάθε
-επιπέδου και απλοποιώντας κατά πολύ την διαδικασία ανάπτυξης και παράδοσης
-κατανεμημένων εφαρμογών. Προσφέροντας μια φιλική προς τον χρήστη διεπαφή,
-έλεγχο εκδόσεων (version control) για δοχεία \cite{LXCvsDocker2} και ένα
-οικοσύστημα γύρω από όλα αυτά, είναι εμφανής ο λόγος που κατάφερε να επισκιάσει
-το LXC.
-
-\subsection{Χρήση δοχείων στην ανάπτυξη και παράδοση εφαρμογών} \label{containerUsage}
-
-Οι μέθοδοι ανάπτυξης και παράδοσης εφαρμογών έχουν αλλάξει δραματικά τα
-τελευταία χρόνια. Από τις παραδοσιακές μεθόδους, όπως το μοντέλο καταρράκτη
-(waterfall) \cite{waterfall} βάσει του οποίου υπήρχε ένα συγκεκριμένο
-αμετάβλητο σχέδιο που καλούνταν να ακολουθήσει μια ομάδα ανάπτυξης λογισμικού,
-έχουμε φτάσει σε μια εποχή όπου οι απαιτήσεις της αγοράς αλλάζουν συνεχώς, με
-αποτέλεσμα να υπάρχει ανάγκη για καινούριες μεθόδους που να ανταποκρίνονται
-στις αλλαγές αυτές. Έτσι, έχουν δημιουργηθεί μεθοδολογίες όπως η Agile
-\cite{agile} κατά την οποία η ανάπτυξη και η παράδοση λογισμικού
-πραγματοποιείται σε πολλές μικρές και ευμετάβλητες φάσεις προκειμένου να
-προσαρμόζεται στις αλλαγές που ενδέχεται να υπάρξουν στον αρχικό σχεδιασμό. Η
-μεθοδολογία αυτή συνεργάζεται με πρακτικές όπως το DevOps \cite{devops} όπου οι
-ομάδες υπεύθυνες για την ανάπτυξη και λειτουργία μιας εφαρμογής επικοινωνούν
-στενά με σκοπό να υπάρχει μια συνεχής ροή παραγωγής και παράδοσης λογισμικού.
-Αυτό επιτυγχάνεται με μια υποκατηγορία του DevOps, το CI/CD (Continuous
-Integration/Continuous Delivery) (Συνεχής Ενοποίηση/Συνεχής Παράδοση)
-\cite{cicd}. Κατά το μοντέλο αυτό, δημιουργούνται αυτοματοποιημένες διαδικασίες
-που εκτελούνται κατά την διάρκεια της ανάπτυξης και παράδοσης μιας εφαρμογής
-προκειμένου να πραγματοποιείται έλεγχος της ποιότητας του κώδικα, να
-εντοπίζονται σφάλματα και να παράγονται εκτελέσιμα πακέτα τα οποία μετά μπορούν
-απευθείας να διατίθενται στο κοινό (continuous deployment).
-
-Τα δοχεία αποτελούν ιδανική επιλογή για την εφαρμογή των παραπάνω μεθοδολογιών
-και πρακτικών καθώς επιτρέπουν το γρήγορο και αποτελεσματικό πακετάρισμα
-εφαρμογών και την εκτέλεσή τους σε οποιοδήποτε περιβάλλον. Λόγω των
-χαρακτηριστικών τους, εξαλείφουν τυχόν προβλήματα ασυμβατότητας μεταξύ των
-περιβαλλόντων εκτέλεσής τους και προσφέρουν μεγαλύτερη αποδοτικότητα πόρων αφού
-μπορεί κανείς να εκτελέσει πολλά περισσότερα αντίγραφα ενός προγράμματος για
-συγκεκριμένη ποσότητα πόρων σε σχέση με τον αριθμό που θα μπορούσε να εκτελέσει
-χρησιμοποιώντας εικονικές μηχανές πάνω από αυτούς τους πόρους. Γεγονός που
-μειώνει ιδιαίτερα το κόστος λειτουργίας και αυξάνει την κλιμακωσιμότητα.
-Επιπλέον, λόγω της ταχείας διάθεσης και εκτέλεσής τους, συμβαδίζουν πλήρως με
-τον ρυθμό ανάπτυξης και παράδοσης που υποστηρίζουν οι παραπάνω μεθοδολογίες.
-Έχοντας αυτά υπόψιν, γίνεται εμφανής και ο λόγος που τα δοχεία είναι η
-προτιμότερη επιλογή για την ανάπτυξη και παράδοση εφαρμογών που ακολουθούν την
-αρχιτεκτονική μικρο-υπηρεσιών. Επιπρόσθετα, η ανεξαρτησία των δοχείων μεταξύ
-τους, καθιστά πιο σταθερή την εφαρμογή αφού σε περίπτωση που κάποιο από αυτά
-αποτύχει, η υπόλοιπη εφαρμογή θα συνεχίσει να λειτουργεί κανονικά και η
-ανακατασκευή του δοχείου που απέτυχε μπορεί να επιτευχθεί εύκολα και γρήγορα με
-μια απλή τροποποίηση της εκάστοτε εικόνας δοχείου.
-
-\subsection{Χρήσεις του Docker στο νέφος} \label{dockerInCloudComputing}
-
-Οι δυνατότητες που προσφέρει το Docker το καθιστούν την καταλληλότερη επιλογή
-τόσο για επιχειρήσεις που λειτουργούν αποκλειστικά με ενοικιαζόμενους
-υπολογιστικούς πόρους όσο και για αυτές που επιλέγουν να λειτουργούν με έναν
-συνδυασμό ενοικιαζόμενων και ιδιόκτητων φυσικών εγκαταστάσεων. Υπάρχουν δύο
-βασικές περιπτώσεις χρήσης του Docker στο νέφος. Συγκεκριμένα αυτές είναι: η
-εγκατάσταση δοχείων σε εικονικές μηχανές και η εγκατάσταση δοχείων έμμεσα σε
-πόρους χωρίς την ανάγκη δημιουργίας εικονικής μηχανής. Η δεύτερη περίπτωση
-χρήσης εντάσσεται στην κατηγορία υπηρεσιών CaaS \cite{caas} (Container as a
-Service), όπως η ECS (Elastic Container Service) της Amazon. Μια υπηρεσία όπου
-ένας πάροχος νέφους αντί να παρέχει πρόσβαση σε υπολογιστικούς πόρους γενικού
-σκοπού, παρέχει μια ευέλικτη υποδομή, έτοιμη για την εκτέλεση δοχείων
-\cite{caasVsIaas}.
-
-Από τις δύο αυτές επιλογές, η πρώτη προσφέρει μια ευελιξία ως προς την
-διαμόρφωση του περιβάλλοντος εκτέλεσης των δοχείων. Οι χρήστες έχουν την
-δυνατότητα να ακολουθήσουν ορισμένες ορθές πρακτικές ασφαλείας που μπορεί να
-έχουν θεσπιστεί στην εταιρεία τους, να εγκαταστήσουν επιπλέον λογισμικό
-παρακολούθησης και ελέγχου ποιότητας των δοχείων και να προσαρμόσουν το
-περιβάλλον εκτέλεσης των δοχείων στις ανάγκες τους. Επιπλέον, η ύπαρξη μιας
-επιπλέον στρώσης απομόνωσης μεταξύ των δοχείων και του κύριου συστήματος
-αποτελεί ένα επιπρόσθετο εμπόδιο σε περιπτώσεις που ένα δοχείο βρεθεί σε
-κατάσταση παραβίασης. Το Docker επιτρέποντας μέσω των δοχείων την περιορισμένη
-έκθεση των πόρων του συστήματος στον έξω κόσμο, καθιστά ευκολότερη την
-ανίχνευση και απομόνωση των προβλημάτων ασφαλείας, καθώς επίσης και την
-αποκατάστασή τους.
-
-Από την άλλη, η δεύτερη περίπτωση χρήσης επιτρέπει στους χρήστες να
-επικεντρωθούν στην ανάπτυξη των δοχειοποιημένων εφαρμογών και να αφήσουν την
-διαχείριση της υποδομής στον πάροχο νέφους. Αυτό είναι ιδιαίτερα χρήσιμο σε
-περιπτώσεις που οι χρήστες δεν έχουν την απαραίτητη εμπειρία σε αυτόν τον τομέα
-ή δεν είναι σε θέση να διαθέσουν τον απαιτούμενο χρόνο για αυτό. Η χρήση
-υπηρεσιών CaaS αυτομάτως εξασφαλίζει στους χρήστες τα πλεονεκτήματα των
-υπηρεσιών IaaS όπως η κλιμάκωση, η αντοχή σε αποτυχίες και η ευελιξία, ενώ
-ταυτόχρονα προσφέρει και τα πλεονεκτήματα των δοχείων, όπως η ταχεία διάθεση
-και απόσυρσή τους αλλά και η υψηλή τους απόδοση κατά την εκτέλεση.
-Συγκεκριμένα, μέσω των υπηρεσιών CaaS, οι χρήστες διαθέτουν δυνατότητες
-ενορχήστρωσης δοχείων \cite{howCaasWorks} χωρίς την ανάγκη χειροκίνητου
-στησίματος πλατφορμών όπως το Kubernetes \cite{kubernetes} και το Docker Swarm
-\cite{dockerSwarm}, που παρέχουν αυτή την δυνατότητα.
-
-Σε κάθε περίπτωση, λόγω των πλεονεκτημάτων που παρέχει η χρήση δοχείων, είναι
-πολύ συνήθης η θέση σε λειτουργία, εφαρμογών μέσω Docker σε περιβάλλοντα νέφους
-επειδή απομονώνει τις αναγκαίες βιβλιοθήκες και εξαρτήσεις τους από το υπόλοιπο
-σύστημα και επιτρέπει την αποδοτικότερη διαχείριση των εφαρμογών αυτών μέσω της
-διεπαφής του με εντολές για εκκίνηση, επιτήρηση πόρων, παύση και άλλες
-λειτουργίες. Τα προβλήματα που μπορεί να προέκυπταν σε ένα περιβάλλον
-ανάπτυξης, όπως μη συμβατές εκδόσεις προγραμμάτων και η δυσκολία διαχείρισής
-τους, εξαλείφονται με την χρήση δοχείων αφήνοντας το Docker να εγκαθιδρύσει
-έναν συστημικό τρόπο διανομής και ελέγχου εφαρμογών. Επιπροσθέτως, καθιστά πολύ
-εύκολη τη μεταφορά τους σε οποιοδήποτε μηχάνημα (εφόσον αυτό υποστηρίζει την
-εκτέλεση της μηχανής δοχείων του Docker) ή ακόμα και νέφος, θέτοντας το
-κορυφαία επιλογή για επιχειρήσεις που επιλέγουν να ακολουθήσουν την στρατηγική
-πολλαπλών νεφών (multi-cloud computing) κατά την κατασκευή εφαρμογών. Δηλαδή να
-μην βασίζονται αποκλειστικά σε έναν πάροχο νέφους για όλες τις λειτουργίες μιας
-εφαρμογής \cite{multiCloud} αλλά να εκμεταλλεύονται οφέλη από πολλούς παρόχους
-με βάση τις ανάγκες τους.
-
-\section{Ασφάλεια του συστήματος κατά τη χρήση του Docker} \label{dockerSecurity}
+\section{Ασφάλεια συστήματος κατά τη χρήση του Docker} \label{dockerSecurity}
 
 Μία από τις πιο σημαντικές προκλήσεις των επιχειρήσεων κατά την διάθεση
 υπηρεσιών είναι η επίτευξη και διατήρηση της ασφάλειας. Παραδοσιακά, κατά την
@@ -393,8 +158,8 @@ Service), όπως η ECS (Elastic Container Service) της Amazon. Μια υπ
 αρχικές ρυθμίσεις.
 
 Για τον λόγο αυτό, εάν η μέγιστη δυνατή απόδοση δεν είναι μια από τις κύριες
-προτεραιότητες της επιχείρησης, προκειμένου να αυξηθεί η ασφάλεια του
-συστήματος διατηρώντας τα πλεονεκτήματα του Docker όσον αφορά την
+προτεραιότητες μιας επιχείρησης, προκειμένου να αυξηθεί η ασφάλεια του
+συστήματός της, διατηρώντας τα πλεονεκτήματα του Docker όσον αφορά την
 μεταφερσιμότητα και την απαλλαγή από τις εξαρτήσεις του εκάστοτε προγράμματος
 ακόμα και χωρίς την περαιτέρω διαμόρφωση των ρυθμίσεών του, η προτεινόμενη
 χρήση είναι η εκτέλεσή του μέσω μιας εικονικής μηχανής. Σε περιπτώσεις
@@ -402,10 +167,13 @@ Service), όπως η ECS (Elastic Container Service) της Amazon. Μια υπ
 ανάμεσα στα προγράμματα και το μηχάνημα στο οποίο εκτελούνται αποτελεί ένα
 παραπάνω εμπόδιο που θα πρέπει να ξεπεράσει ένας επιτιθέμενος για να προκαλέσει
 ζημιές στο κύριο σύστημα, αφού θα πρέπει πρώτα να περάσει από τον εικονικό
-πυρήνα και έπειτα από τον υπερ-επόπτη. Παράλληλα, ο συνδυασμός με την
-αρχιτεκτονική δοχείων παρέχει ένα επιπρόσθετο επίπεδο απομόνωσης εφόσον στην
-προκειμένη περίπτωση η άμεση επικοινωνία με τον πυρήνα του συστήματος αφορά το
-φιλοξενούμενο ΛΣ και όχι το κύριο σύστημα.
+πυρήνα (πυρήνα ΛΣ της εικονικής μηχανής) και έπειτα από τον υπερ-επόπτη.
+Παράλληλα, ο συνδυασμός με την αρχιτεκτονική δοχείων παρέχει ένα επιπρόσθετο
+επίπεδο απομόνωσης εφόσον στην προκειμένη περίπτωση η άμεση επικοινωνία με τον
+πυρήνα του συστήματος αφορά το φιλοξενούμενο ΛΣ και όχι το κύριο σύστημα.
+Συνεπώς, ένας επιτιθέμενος πρέπει να πραγματοποιήσει δύο αποδράσεις. Μια από
+την μηχανή ενορχήστρωσης δοχείων ή περιβάλλον δοχειοποίησης και έπειτα μια
+επιπλέον από το εικονικοποιημένο περιβάλλον.
 
 Παρ' όλα αυτά, υπάρχουν περιπτώσεις όπου η απόδοση του συστήματος δεν δύναται
 να θυσιαστεί για χάρη της ασφάλειας. Σε αυτές τις περιπτώσεις, επιβάλλεται η
@@ -419,11 +187,13 @@ Service), όπως η ECS (Elastic Container Service) της Amazon. Μια υπ
 να ληφθεί υπόψιν το ποσοστό των υποδομών που βρίσκεται υπό την ευθύνη του
 χρήστη και να θεωρηθεί δεδομένο πως οι πάροχοι νέφους θα ακολουθήσουν όλες τις
 ορθές πρακτικές ασφαλείας για να προστατεύσουν το κομμάτι των υποδομών που τους
-αντιστοιχεί. Σε αυτήν την περίπτωση, εάν ο χρήστης χρησιμοποιεί υπηρεσίες CaaS,
-τότε είναι υπεύθυνος για την ασφάλιση πολύ μικρότερου ποσοστού επιφάνειας
-επίθεσης συγκριτικά με τον πάροχο και επωφελείται άμεσα από τις προσπάθειες
-ασφάλισης του παρόχου για το ποσοστό του. Επομένως, συμπεραίνεται πως από την
-οπτική γωνία του τελικού χρήστη είναι πιο ασφαλές να χρησιμοποιήσει τεχνολογίες
+αντιστοιχεί. Σε αυτήν την περίπτωση, εάν ο χρήστης χρησιμοποιεί υπηρεσίες CaaS
+(Container-as-a-Service) κατά τις οποίες ο πάροχος νέφους προσφέρει υποδομές
+προσαρμοσμένες συγκεκριμένα για την εκτέλεση δοχείων, τότε αυτός είναι
+υπεύθυνος για την ασφάλιση πολύ μικρότερου ποσοστού επιφάνειας επίθεσης
+συγκριτικά με τον πάροχο και επωφελείται άμεσα από τις προσπάθειες ασφάλισης
+του παρόχου για το ποσοστό του. Επομένως, συμπεραίνεται πως από την οπτική
+γωνία του τελικού χρήστη είναι πιο ασφαλές να χρησιμοποιήσει τεχνολογίες
 εικονικοποίησης ΛΣ μέσω ενός παρόχου νέφους για την παροχή των υπηρεσιών του
 \cite{containerSecurityExplained}.
 
@@ -438,20 +208,20 @@ Service), όπως η ECS (Elastic Container Service) της Amazon. Μια υπ
 δοχείων, είναι διακριτή η διευκόλυνση στον εντοπισμό της πηγής τους.
 
 Ένα εξίσου σημαντικό όφελος αποτελεί το επιπρόσθετο επίπεδο ασφάλειας που
-παρέχεται. Σε περιβάλλον εικονικής μηχανής θα πρέπει να σκληρύνει το ΛΣ
+παρέχεται. Σε περιβάλλον εικονικής μηχανής θα πρέπει να σκληρυνθεί το ΛΣ
 φιλοξενίας (αν υπάρχει), ο υπερ-επόπτης, το φιλοξενούμενο ΛΣ και η εκτελούμενη
-υπηρεσία. Σε περιβάλλον δοχείου, πρέπει να σκληρύνει το ΛΣ που φιλοξενεί τη
+υπηρεσία. Σε περιβάλλον δοχείου, πρέπει να σκληρυνθεί το ΛΣ που φιλοξενεί τη
 μηχανή δοχείων, η μηχανή δοχείων και η υπηρεσία. Πράγμα που σημαίνει πως σε ένα
 εικονικό περιβάλλον, με την χρήση του Docker έχουμε επιπρόσθετα επίπεδα που
 χρειάζονται σκλήρυνση. Συνεπώς, σε εικονικά περιβάλλοντα, η χρήση δοχείων
 έρχεται με την σκλήρυνση ενός επιπλέον συστατικού, της μηχανής δοχείων, οπότε
-προσφέρει καλύτερο επίπεδο ασφάλειας.
+αυτή προσφέρει καλύτερο επίπεδο ασφάλειας.
 
 Δύο ακόμα σημαντικά πλεονεκτήματα είναι η ευκολία εφαρμογής ενημερώσεων
 ασφαλείας στα δοχεία και η σταθερότητα του περιβάλλοντος που προσφέρεται μέσω
 αυτών στις εφαρμογές. Ειδικότερα, η ενημέρωση ενός δοχείου είναι μια διαδικασία
 δύο μόνο εντολών, ενώ το προσφερόμενο περιβάλλον είναι σταθερό με την λογική
-πως η μηχανή δοχείων παρέχει ένα επίπεδο πάνω από το ΛΣ, κι επομένως το
+πως η μηχανή δοχείων παρέχει ένα επίπεδο πάνω από το ΛΣ, και επομένως το
 περιβάλλον αυτό δεν είναι ξεχωριστά ευμετάβλητο από την εκάστοτε εφαρμογή που
 εκτελείται μέσα σε αυτό. Άρα, δεν κινδυνεύει από νέα προβλήματα ασφαλείας που
 θα μπορούσαν να επιφέρουν τυχόν ενημερώσεις των εξαρτήσεων της εφαρμογής χωρίς
@@ -481,7 +251,7 @@ Service), όπως η ECS (Elastic Container Service) της Amazon. Μια υπ
 που εκτελούνται στο σύστημα.
 
 Σχετικά με τις επιθέσεις που αποσκοπούν στην απόκτηση πρόσβασης στο κύριο
-σύστημα μέσω του δοχείου, ο κίνδυνος οφείλεται στον τρόπο λειτουργίας των
+σύστημα μέσω ενός δοχείου, ο κίνδυνος οφείλεται στον τρόπο λειτουργίας των
 δοχείων σε συνδυασμό με τις αρχικές ρυθμίσεις ασφαλείας του Docker. Λόγω της
 απευθείας επικοινωνίας τους με τον πυρήνα του συστήματος, τα δοχεία είναι άμεσα
 ευεπηρέαστα από ευπάθειες του πυρήνα. Συνεπώς, ένας επιτιθέμενος που στοχεύει
@@ -490,7 +260,7 @@ Service), όπως η ECS (Elastic Container Service) της Amazon. Μια υπ
 διαχειριστικά δικαιώματα, μετά από μια επιτυχημένη επίθεση Container Escape θα
 έχει διαχειριστικά δικαιώματα και ο ίδιος \cite{containerEscapeRepercussions}.
 
-\subsection{Ξεπερνώντας τα μειονεκτήματα ασφαλείας του Docker} \label{overcomingDockerDisadvantages}
+\section{Συνεισφορά Διπλωματικής} \label{overcomingDockerDisadvantages}
 
 Οι πιο συνήθεις τρόποι αντιμετώπισης της ανεπαρκούς προκαθορισμένης ασφάλειας
 του Docker (δηλ. της ελαστικής απομόνωσης) είναι η ρύθμιση καλύτερων προφίλ
@@ -505,17 +275,18 @@ Docker, όπως η σκλήρυνσή του, η αποφυγή χρήσης τ
 καθώς και να εγκαθιστά σε αυτά, με βάση τις προαναφερόμενες οδηγίες προστασίας
 του Docker και των δοχείων του, μια σκληρυμένη έκδοση του Docker.
 
-Με τη χρήση του εργαλείου SecDep που αναπτύχθηκε στα πλαίσια της παρούσας
-διπλωματικής εργασίας, το οποίο θα περιγράψουμε παρακάτω στο Κεφάλαιο
-\ref{installationANDShowcase}, θα επιτευχθεί η ασφάλιση του Docker και του
-συστήματος με αυτοματοποιημένο τρόπο ακολουθώντας ορθές πρακτικές,
-χρησιμοποιώντας ένα ασφαλέστερο από το αρχικό Container Runtime και εκτελώντας
-το Docker εξ ολοκλήρου χωρίς την ανάγκη διαχειριστικών δικαιωμάτων. Το εργαλείο
-αυτό εστιάζει στην χρήση εικονικοποιημένων περιβαλλόντων, μιας και παρέχουν
+Η ανάγκη αυτή ικανοποιήθηκε με την ανάπτυξη του εργαλείου SecDep (Secure
+Deployment) που αναπτύχθηκε στα πλαίσια της παρούσας διπλωματικής εργασίας, το
+οποίο θα περιγράψουμε παρακάτω στο Κεφάλαιο \ref{installationANDShowcase}. Με
+την χρήση του, θα επιτευχθεί η ασφάλιση του Docker και του συστήματος με
+αυτοματοποιημένο τρόπο ακολουθώντας ορθές πρακτικές, χρησιμοποιώντας ένα
+ασφαλέστερο από το αρχικό Container Runtime και εκτελώντας το Docker εξ
+ολοκλήρου χωρίς την ανάγκη διαχειριστικών δικαιωμάτων. Το εργαλείο αυτό
+εστιάζει στην χρήση εικονικοποιημένων περιβαλλόντων, μιας και παρέχουν
 περισσότερα επίπεδα προς διείσδυση για έναν επιτιθέμενο, εμποδίζοντάς τον στην
 επίτευξη του στόχου αυτού. Επικοινωνεί με πολλούς παρόχους νέφους στέλνοντάς
 τους παραμέτρους για τις προδιαγραφές εικονικών μηχανών προκειμένου να
-μπορέσουν να δημιουργηθούν αυτόματα. Με αυτόν τον τρόπο, επιτρέπει την
+μπορέσουν αυτές να δημιουργηθούν αυτόματα. Με αυτόν τον τρόπο, επιτρέπει την
 δημιουργία πολλαπλών ασφαλών περιβαλλόντων ώστε να μπορεί ένας χρήστης να
 εγκαθιστά εκεί τα δοχεία της εφαρμογής του. Με την εφαρμογή των κατάλληλων
 μέτρων και πρακτικών ασφαλείας σε κάθε επίπεδο, τα περιβάλλοντα αυτά
@@ -523,7 +294,7 @@ Docker, όπως η σκλήρυνσή του, η αποφυγή χρήσης τ
 επιτυγχάνεται με την εκτέλεση πολλών βημάτων στα οποία μεταξύ άλλων
 περιλαμβάνεται η σκλήρυνση του SSH, ο εντοπισμός, η εγκατάσταση, η ρύθμιση και
 η ενεργοποίηση των κατάλληλων για την εκάστοτε διανομή, προγραμμάτων για
-ανάχωμα ασφαλείας και για παροχή MAC (Mandatory Access Control) και η
+ανάχωμα ασφαλείας και για παροχή MAC (Mandatory Access Control) καθώς και η
 δημιουργία και ενεργοποίηση περιοδικά εκτελέσιμων προγραμμάτων για την
 ενημέρωση του συστήματος και το άνοιγμα/κλείσιμο θυρών προγραμμάτων. Η
 απεξάρτηση από τον διαχειριστικό λογαριασμό επιτυγχάνεται χάρη στη δουλειά του
@@ -540,21 +311,20 @@ Akihiro Suda πάνω στο rootlesskit \footfullcite{AkihiroSuda}, επιτρ
 πλούσια τεκμηρίωση και οδηγίες εγκατάστασης στο αποθετήριό του, ενώ οι γνώσεις
 που απαιτούνται στον τομέα των τεχνολογιών νέφους για την χρήση του είναι
 ελάχιστες. Επιπλέον, είναι ευέλικτο και επεκτάσιμο διότι αποτελείται από δύο
-εκτελέσιμα προγράμματα τα οποία μπορεί κάθε χρήστης να τροποποιήσει ώστε να
+εκτελέσιμα προγράμματα, τα οποία μπορεί κάθε χρήστης να τροποποιήσει ώστε να
 προσθέσει τις δικές του λειτουργίες αν το επιθυμεί. Τέλος, οι παράμετροι του
 είναι εύκολα κατανοητές και προσαρμόσιμες στις ανάγκες του χρήστη. Επομένως, το
 εργαλείο αυτό αποτελεί ένα κατάλληλο μέσο για την δημιουργία, διαχείριση και
-ασφάλιση περιβαλλόντων εφαρμογών που εκτελούνται σε δοχεία.
-
-\clearpage
+ασφάλιση περιβαλλόντων δοχειοποιημένων εφαρμογών (containerized applications),
+δηλ. εφαρμογών που παίρνουν την μορφή δοχείων.
 
 \section{Δομή Εργασίας} \label{structure}
 
 Η υπόλοιπη δομή της αναφοράς είναι η εξής. Στο Κεφάλαιο \ref{background}, θα
 αναλύσουμε τις έννοιες της νεφο-υπολογιστικής και εικονικοποίησης, τις διάφορες
 τεχνολογίες εικονικοποίησης και θα εμβαθύνουμε στην τεχνολογία των δοχείων με
-επίκεντρο την ασφάλεια του Docker. Στο επόμενο κεφάλαιο (δηλαδή το
-\ref{relevantWork}), θα δούμε εργασίες σχετικές με την παρούσα και θα
+επίκεντρο την ασφάλεια του Docker. Στο επόμενο κεφάλαιο (δηλαδή το Κεφάλαιο
+\ref{relevantWork}), θα παρουσιάσουμε εργασίες σχετικές με την παρούσα και θα
 πραγματοποιηθεί ανάλυση και σύγκριση αυτών με την προτεινόμενη εργασία της
 διπλωματικής. Αμέσως μετά, στο Κεφάλαιο \ref{projectDevelopment}, αναφερόμαστε
 στην διαδικασία ανάπτυξης του προτεινόμενου εργαλείου και τα παράγωγά της
diff --git a/Chapters/2.Background.tex b/Chapters/2.Background.tex
index b4a2fd9..a459504 100644
--- a/Chapters/2.Background.tex
+++ b/Chapters/2.Background.tex
@@ -4,15 +4,16 @@
 
 \noindent Προκειμένου να κατανοήσουμε πλήρως το πρόβλημα που επιλύει η παρούσα
 εργασία πρέπει να αναλύσουμε μερικές βασικές έννοιες. Αρχικά, θα δούμε τι είναι
-το υπολογιστικό νέφος, τι μας προσφέρει και ποια μοντέλα παράδοσης παρέχονται
-μέσω αυτού. Έπειτα, θα συζητήσουμε την έννοια της εικονικοποίησης και τις
-διάφορες υποκατηγορίες της που χρησιμοποιούνται στις μέρες μας. Αμέσως μετά, θα
-αναλυθούν τα πλεονεκτήματα της εικονικοποίησης και θα αναδειχθεί ο λόγος που
-προτιμάται η εικονικοποίηση του λειτουργικού συστήματος (δηλ. η χρήση
-δοχειοποιημένων περιβαλλόντων). Τέλος, θα εμβαθύνουμε στην τεχνολογία δοχείων,
-θα δούμε διάφορες υλοποιήσεις της και θα πραγματοποιήσουμε μια ανάλυση της
-ασφάλειας του Docker, ως το de facto βιομηχανικό πρότυπο για την διαχείριση των
-δοχείων, των εφαρμογών και των εικόνων τους.
+το υπολογιστικό νέφος, τι μας προσφέρει, ποια είναι τα μοντέλα ανάπτυξής του
+και ποια μοντέλα παράδοσης παρέχονται μέσω αυτού. Έπειτα, θα συζητήσουμε την
+έννοια της εικονικοποίησης και τις διάφορες υποκατηγορίες της που
+χρησιμοποιούνται στις μέρες μας. Αμέσως μετά, θα αναλυθούν τα πλεονεκτήματα της
+εικονικοποίησης και θα αναδειχθεί ο λόγος που προτιμάται η εικονικοποίηση του
+λειτουργικού συστήματος (δηλ. η χρήση δοχειοποιημένων περιβαλλόντων). Τέλος, θα
+εμβαθύνουμε στην τεχνολογία δοχείων, θα δούμε διάφορες υλοποιήσεις της και θα
+πραγματοποιήσουμε μια ανάλυση της ασφάλειας του Docker, ως το de facto
+βιομηχανικό πρότυπο για την διαχείριση των δοχείων και των εικόνων τους στα
+πλαίσια δοχειοποιημένων εφαρμογών.
 
 \section{Νεφο-υπολογιστική} \label{cloudComputing}
 
@@ -24,7 +25,7 @@
 αναφέρεται στην απομακρυσμένη διάθεση λογισμικού, του οποίου η συμμόρφωση με
 τις λειτουργικές και μη λειτουργικές του ικανότητες που διαφημίζονται προς τους
 πελάτες αποτελεί ευθύνη του παρόχου του. Η κατηγορία PaaS (Platform as a
-Service) (Πλατφόρμα ως Υπηρεσία) ορίζεται ως η διάθεση πλατφόρμας με την οποία
+Service) (Πλατφόρμα ως Υπηρεσία) ορίζεται ως η διάθεση απομακρυσμένης πλατφόρμας με την οποία
 μια ομάδα έργου μπορεί να αναπτύξει συνεργατικά και να εκτελέσει λογισμικό.
 Τέλος, η κατηγορία IaaS (Infrastructure as a Service) μεταφράζεται ως η
 προσφορά απομακρυσμένων (εικονικών και φυσικών) διακομιστών τους οποίους μια
@@ -38,25 +39,27 @@ Service) (Πλατφόρμα ως Υπηρεσία) ορίζεται ως η δ
 προσμετρώνται μόνο οι πόροι που χρησιμοποιήθηκαν.
 
 Σημαντικό ρόλο στην ευρεία αποδοχή των υπηρεσιών που προσφέρονται μέσω της
-νεφο-υπολογιστικής είχε η ευκολία αλλά και ευελιξία των μεθόδων διάθεσης και
+νεφο-υπολογιστικής έχει η ευκολία αλλά και ευελιξία των μεθόδων διάθεσης και
 μετέπειτα διαχείρισής τους. Σε κάθε περίπτωση γίνεται χρήση ενός API
-(Application Programming Interface) (Προγραμματιστική Διεπαφή Εφαρμογής) το
+(Application Programming Interface) (Προγραμματιστική Διεπαφή Εφαρμογής), το
 οποίο είναι προσπελάσιμο έμμεσα μέσω ενός γραφικού περιβάλλοντος (self-service
-portal), ενός εργαλείου γραμμής εντολών ή άμεσα με προγραμματιστικό τρόπο (πχ.
-με τη χρήση SDKs (Software Development Kits)).
+portal) ή ενός εργαλείου γραμμής εντολών (command line tool) ή άμεσα με
+προγραμματιστικό τρόπο (πχ. με τη χρήση SDKs (Software Development Kits) (Κιτ
+Ανάπτυξης Λογισμικού)).
 
 \subsection{Ορισμός Νεφο-Υπολογιστικής} \label{cloudComputingDefinition}
 
 Σύμφωνα με το \citetitle{mell2011nist} \cite{mell2011nist}, η νεφο-υπολογιστική
-είναι ένα μοντέλο που επιτρέπει την ανά πάσα στιγμή διαδικτυακή πρόσβαση σε μια
-κοινή δεξαμενή ρυθμιζόμενων υπολογιστικών πόρων που μπορούν να παρέχονται και
-να απελευθερώνονται γρήγορα και με ελάχιστη προσπάθεια διαχείρισης ή
-αλληλεπίδρασης με τον πάροχο υπηρεσιών. Στους υπολογιστικούς αυτούς πόρους
-περιλαμβάνονται δίκτυα, διακομιστές, χώρος αποθήκευσης, εφαρμογές και
-υπηρεσίες. Αυτό το μοντέλο νέφους αποτελείται από πέντε βασικά χαρακτηριστικά,
-τρία μοντέλα υπηρεσιών (ή μοντέλα παράδοσης) και τέσσερα μοντέλα ανάπτυξης.
+είναι ένα μοντέλο που επιτρέπει την ανά πάσα στιγμή διαδικτυακή πρόσβαση από
+οπουδήποτε σε μια κοινή δεξαμενή ρυθμιζόμενων υπολογιστικών πόρων που μπορούν
+να παρέχονται και να απελευθερώνονται γρήγορα και με ελάχιστη προσπάθεια
+διαχείρισης ή αλληλεπίδρασης με τον πάροχο υπηρεσιών. Στους υπολογιστικούς
+αυτούς πόρους περιλαμβάνονται δίκτυα, διακομιστές, χώρος αποθήκευσης, εφαρμογές
+και υπηρεσίες. Αυτό το μοντέλο νέφους αποτελείται από πέντε βασικά
+χαρακτηριστικά, τρία μοντέλα υπηρεσιών (ή μοντέλα παράδοσης) και τέσσερα
+μοντέλα ανάπτυξης.
 
-\subsubsection{Χαρακτηριστικά} \label{cloucComputingCharacteristics}
+\subsection{Χαρακτηριστικά} \label{cloucComputingCharacteristics}
 
 Τα πέντε βασικά χαρακτηριστικά της νεφο-υπολογιστικής με βάση τους
 \textcite{mell2011nist} είναι τα εξής:
@@ -89,8 +92,8 @@ portal), ενός εργαλείου γραμμής εντολών ή άμεσα
         διακατέχεται και από μια αίσθηση ανεξαρτησίας θέσης διότι ανεξάρτητα
         από το που βρίσκεται ένας τελικός χρήστης μπορεί να χρησιμοποιήσει
         πόρους από οποιοδήποτε κέντρο δεδομένων επιθυμεί. Παραδείγματα πόρων
-        που παρέχονται αποτελούν μεταξύ άλλων το εύρος ζώνης δικτύου, ο
-        αποθηκευτικός χώρος και οι εικονικές μηχανές.
+        που παρέχονται αποτελούν μεταξύ άλλων το εύρος ζώνης δικτύου (network
+        bandwidth), ο αποθηκευτικός χώρος και οι εικονικές μηχανές.
 
     \item \textbf{Ελαστικότητα (Elasticity)}:
 
@@ -104,7 +107,7 @@ portal), ενός εργαλείου γραμμής εντολών ή άμεσα
     \item \textbf{Μετρούμενη υπηρεσία (Measured Service)}:
 
         Τα συστήματα νέφους ελέγχουν και βελτιστοποιούν αυτόματα τη χρήση των
-        πόρων αξιοποιώντας δυνατότητες μέτρησης/παρακολούθησης κατάλληλες για
+        πόρων, αξιοποιώντας δυνατότητες μέτρησης/παρακολούθησης κατάλληλες για
         τον τύπο της υπηρεσίας (π.χ, αποθήκευση, επεξεργασία, εύρος ζώνης). Η
         χρήση των πόρων μπορεί να παρακολουθείται, να ελέγχεται και να
         καταγράφεται, παρέχοντας διαφάνεια τόσο στον πάροχο όσο και στον
@@ -116,7 +119,7 @@ portal), ενός εργαλείου γραμμής εντολών ή άμεσα
 
 \clearpage
 
-\subsubsection{Μοντέλα Υπηρεσιών/Παράδοσης} \label{cloudComputingServiceModels}
+\subsection{Μοντέλα Υπηρεσιών/Παράδοσης} \label{cloudComputingServiceModels}
 
 Τα τρία μοντέλα υπηρεσιών ή παράδοσης της νεφο-υπολογιστικής, όπως αυτά
 αναγράφονται στο \cite{mell2011nist}, είναι τα παρακάτω:
@@ -131,11 +134,11 @@ portal), ενός εργαλείου γραμμής εντολών ή άμεσα
         από διάφορες συσκευές ικανές να συνδεθούν στο διαδίκτυο, μέσω
         φυλλομετρητή ή προγραμματιστικής διεπαφής. Δεν προσφέρεται έλεγχος ή
         δυνατότητα διαχείρισης της υποκείμενης υποδομής νέφους ή των
-        δυνατοτήτων της υπηρεσίας, με εξαίρεση περιορισμένη παραμετροποίηση
-        κάποιων ρυθμίσεων διαμόρφωσης της εφαρμογής. Το μοντέλο χρέωσης
-        είθισται να είναι της μορφής μιας σταθερής μηνιαίας ή ετήσιας συνδρομής
-        χρησιμοποιώντας βαθμίδες με διαφορετικά επίπεδα παροχής υπηρεσιών του
-        λογισμικού \cite{saasPricingModel}.
+        δυνατοτήτων της υπηρεσίας (λογισμικού), με εξαίρεση περιορισμένη
+        παραμετροποίηση κάποιων ρυθμίσεων διαμόρφωσης της εφαρμογής. Το μοντέλο
+        χρέωσης είθισται να είναι της μορφής μιας σταθερής μηνιαίας ή ετήσιας
+        συνδρομής χρησιμοποιώντας βαθμίδες με διαφορετικά επίπεδα παροχής
+        υπηρεσιών του λογισμικού \cite{saasPricingModel}.
 
     \item \textbf{Platform as a Service (PaaS) (Πλατφόρμα ως Υπηρεσία)}:
 
@@ -164,27 +167,27 @@ portal), ενός εργαλείου γραμμής εντολών ή άμεσα
     \item \textbf{Infrastructure as a Service (IaaS) (Υποδομή ως Υπηρεσία)}:
 
         Παρέχεται η δυνατότητα χρήσης επεξεργαστικών, αποθηκευτικών, δικτυακών
-        και άλλων υπολογιστικών πόρων. Συνήθως, οι πόροι αυτοί συγκροτούνται
-        στην μορφή μιας εικονικής μηχανής, δηλ. ενός απογυμνωμένου
-        περιβάλλοντος στο οποίο ο καταναλωτής μπορεί να εγκαταστήσει και να
-        εκτελέσει το λογισμικό της επιλογής του, συμπεριλαμβανομένων
-        λειτουργικών συστημάτων και εφαρμογών. Ο καταναλωτής δεν έχει τον
-        έλεγχο της υποκείμενης υποδομής νέφους, αλλά έχει τον έλεγχο των
-        λειτουργικών συστημάτων, του αποθηκευτικού χώρου, των περιβαλλόντων
-        ανάπτυξης/εκτέλεσης, των εγκατεστημένων εφαρμογών, των δεδομένων τους
-        και των ρυθμίσεων διαμόρφωσής τους. Το μοντέλο χρέωσης υπηρεσιών IaaS
-        συνήθως αποτελείται από μια συνεχόμενη χρέωση ανά χρονική περίοδο λόγω
-        της ανάθεσης των πόρων στον καταναλωτή, η οποία αυξάνεται μετά την
-        υπέρβαση ενός ορίου χρήσης για ορισμένους πόρους, όπως το εύρος ζώνης
-        δικτύου.
+        και άλλων ειδών υπολογιστικών πόρων. Συνήθως, οι πόροι αυτοί
+        συγκροτούνται στην μορφή μιας εικονικής μηχανής, δηλ. ενός
+        απογυμνωμένου περιβάλλοντος στο οποίο ο καταναλωτής μπορεί να
+        εγκαταστήσει και να εκτελέσει το λογισμικό της επιλογής του,
+        συμπεριλαμβανομένων λειτουργικών συστημάτων και εφαρμογών. Ο
+        καταναλωτής δεν έχει τον έλεγχο της υποκείμενης υποδομής νέφους, αλλά
+        έχει τον έλεγχο των λειτουργικών συστημάτων, του αποθηκευτικού χώρου,
+        των περιβαλλόντων ανάπτυξης/εκτέλεσης, των εγκατεστημένων εφαρμογών,
+        των δεδομένων τους και των ρυθμίσεων διαμόρφωσής τους. Το μοντέλο
+        χρέωσης υπηρεσιών IaaS συνήθως αποτελείται από μια συνεχόμενη χρέωση
+        ανά χρονική περίοδο λόγω της ανάθεσης των πόρων στον καταναλωτή, η
+        οποία αυξάνεται μετά την υπέρβαση ενός ορίου χρήσης για ορισμένους
+        πόρους, όπως το εύρος ζώνης δικτύου.
 
 \end{itemize}
 
-\subsubsection{Μοντέλα Ανάπτυξης} \label{cloudComputingDeploymentModels}
+\subsection{Μοντέλα Ανάπτυξης} \label{cloudComputingDeploymentModels}
 
 Τα τέσσερα μοντέλα ανάπτυξης του υπολογιστικού νέφους σύμφωνα με το
 \cite{mell2011nist} και την \citeauthor{cloudDeploymentModels}
-\cite{cloudDeploymentModels} είναι:
+\cite{cloudDeploymentModels} είναι τα εξής:
 
 \begin{itemize}
 
@@ -197,7 +200,7 @@ portal), ενός εργαλείου γραμμής εντολών ή άμεσα
     νέφος αυτό μπορεί να βρίσκεται εντός ή εκτός του οργανισμού (πχ. στην
     περίπτωση που λειτουργεί από τρίτη οντότητα). Παρέχει πλήρη έλεγχο στον
     τρόπο με τον οποίο μοιράζονται και αποθηκεύονται τα δεδομένα και
-    διασφαλίζει την συμμόρφωση με τυχόν κανονισμούς τους οποίους καλείται ένας
+    διασφαλίζει την συμμόρφωση με τυχόν κανονισμούς, τους οποίους καλείται ένας
     οργανισμός να ακολουθήσει. Επιπλέον, λόγω της αποκλειστικής αφιέρωσής του
     σε έναν μόνο οργανισμό, εξασφαλίζεται η διαθεσιμότητα των δεδομένων κατά
     παραγγελία, όπως επίσης και η αξιοπιστία του για κρίσιμους φόρτους
@@ -214,12 +217,14 @@ portal), ενός εργαλείου γραμμής εντολών ή άμεσα
         συμμόρφωσης. Μπορεί να ανήκει, να διαχειρίζεται και να λειτουργεί από
         έναν ή περισσότερους οργανισμούς της κοινότητας, μια τρίτη οντότητα ή
         έναν συνδυασμό των δύο. Το νέφος αυτό μπορεί να βρίσκεται εντός ή εκτός
-        των οργανισμών της κοινότητας (εφόσον λειτουργεί από τρίτη κοινότητα).
+        των οργανισμών της κοινότητας (εφόσον λειτουργεί από ένα τρίτο μέρος).
         Το κόστος κτήσης, λειτουργίας και συντήρησης του νέφους συνήθως
         διαμοιράζεται μεταξύ των μελών/οργανισμών της κοινότητας. Επιπροσθέτως,
         το νέφος αυτού του είδους είναι προσβάσιμο συνήθως μόνο από τα μέλη της
         κοινότητας. Οπότε, μπορεί να θεωρηθεί ένα ιδιωτικό νέφος, όμως όχι μόνο
-        για έναν αλλά για πολλαπλούς οργανισμούς.
+        για έναν αλλά για πολλαπλούς οργανισμούς. Το επίπεδο ασφάλειας που
+        μπορεί να επιτευχθεί σε αυτό το είδος νέφους είναι υψηλότερο από το
+        δημόσιο νέφος και χαμηλότερο από το ιδιωτικό.
 
     \item \textbf{Δημόσιο νέφος (Public Cloud)}:
 
@@ -227,17 +232,19 @@ portal), ενός εργαλείου γραμμής εντολών ή άμεσα
         ανήκει και να διαχειρίζεται από μια επιχείρηση, έναν ακαδημαϊκό ή
         κυβερνητικό οργανισμό ή έναν συνδυασμό των παραπάνω. Λειτουργεί εντός
         των υποδομών του παρόχου νέφους. Το δημόσιο νέφος προσφέρει είτε
-        εικονικές μηχανές που εκτελούνται σε διακομιστές του παρόχου νέφους,
-        των οποίων οι υπολογιστικοί πόροι χρησιμοποιούνται από πολλούς
+        εικονικές μηχανές που εκτελούνται σε (φυσικούς) διακομιστές του παρόχου
+        νέφους, των οποίων οι υπολογιστικοί πόροι χρησιμοποιούνται από πολλούς
         καταναλωτές ταυτόχρονα, είτε τους φυσικούς του διακομιστές για
         αποκλειστική χρήση. Αποτελεί το πιο δημοφιλές μοντέλο που παρέχουν
         εταιρείες υπηρεσιών IaaS λόγω της απουσίας απαίτησης μεγάλου αρχικού
-        κόστους και της ευελιξίας που παρέχεται μέσω της αυτοεξυπηρέτησης κατά
-        παραγγελία. Είναι η κατάλληλη επιλογή για μεγάλους φόρτους εργασίας
-        μικρής διάρκειας λόγω του μοντέλου χρέωσης ανά χρήση ενώ διευκολύνει
-        μια επιχείρηση στην μετέπειτα διαχείριση του κόστους με βάση τις
-        προβλέψεις της ζήτησης της υπηρεσίας που αυτή προσφέρει και των
-        δυνατοτήτων κλιμάκωσης υπηρεσιών που το νέφος παρέχει σε αυτήν.
+        κόστους επένδυσης και της ευελιξίας που παρέχεται μέσω της
+        αυτοεξυπηρέτησης κατά παραγγελία. Είναι η κατάλληλη επιλογή για
+        μεγάλους φόρτους εργασίας μικρής διάρκειας λόγω του μοντέλου χρέωσης
+        ανά χρήση ενώ διευκολύνει μια επιχείρηση στην μετέπειτα διαχείριση του
+        κόστους με βάση τις προβλέψεις της ζήτησης της υπηρεσίας που αυτή
+        προσφέρει και των δυνατοτήτων κλιμάκωσης υπηρεσιών που το νέφος παρέχει
+        σε αυτήν. Όμως, το επίπεδο ασφάλειας του δημόσιου νέφους είναι το
+        χαμηλότερο σε σχέση με τα άλλα 3 είδη νέφους.
 
     \item \textbf{Υβριδικό νέφος (Hybrid Cloud)}:
 
@@ -260,42 +267,46 @@ portal), ενός εργαλείου γραμμής εντολών ή άμεσα
 πόρων, όπως είναι οι διακομιστές, το λειτουργικό σύστημα, ακόμα και τα
 δεδομένα. Η πιο συνηθισμένη χρήση εικονικοποίησης είναι αυτή των διακομιστών η
 οποία αποτελεί και τον πυλώνα της νεφο-υπολογιστικής. Προκειμένου να
-επιτευχθεί, απαιτείται η χρήση ενός υπερ-επόπτη. Δηλαδή ενός λογισμικού
+επιτευχθεί, απαιτείται η χρήση ενός υπερ-επόπτη. Δηλαδή, ενός λογισμικού
 υπεύθυνου για την κατάτμηση των φυσικών πόρων ενός διακομιστή σε μια ή
 περισσότερες εικονικές αναπαραστάσεις ενός συνόλου αυτών με σκοπό να
-χρησιμοποιηθούν ως ξεχωριστοί εικονικοί διακομιστές (virtual hosts/servers).
+χρησιμοποιηθούν ως ξεχωριστοί εικονικοί διακομιστές (virtual hosts/servers) (οι
+κοινώς λεγόμενες εικονικές μηχανές).
 
-Για έναν υπερ-επόπτη υπάρχουν δύο κατηγορίες στις οποίες μπορεί να ανήκει. Είτε
-πρόκειται για υπερ-επόπτη τύπου 1 στην περίπτωση απευθείας πρόσβασης στο υλικό,
-είτε τύπου 2 εάν υπάρχει ήδη λειτουργικό σύστημα εγκατεστημένο στον υποκείμενο
-διακομιστή προς κατάτμηση. Η επιλογή τύπου υπερ-επόπτη είναι άμεσα εξαρτώμενη
-από τις ανάγκες του κάθε χρήστη. Στην περίπτωση που η ταχύτητα και η απόδοση
-είναι σημαντικά μη λειτουργικά χαρακτηριστικά που πρέπει να έχουν υψηλές τιμές,
-η άμεση πρόσβαση του υπερ-επόπτη τύπου 1 στο υλικό συμβάλλει στην επίτευξη της
+Ένας υπερ-επόπτης μπορεί να ανήκει σε δύο αποκλειστικές κατηγορίες. Είτε
+πρόκειται για υπερ-επόπτη τύπου 1 στην περίπτωση απευθείας πρόσβασης με το
+υλικό, είτε τύπου 2 εάν υπάρχει ήδη λειτουργικό σύστημα εγκατεστημένο στον
+υποκείμενο (φυσικό) διακομιστή προς κατάτμηση. Η επιλογή τύπου υπερ-επόπτη
+είναι άμεσα εξαρτώμενη από τις ανάγκες του κάθε χρήστη. Στην περίπτωση που η
+υψηλή ταχύτητα και απόδοση είναι σημαντικές μη λειτουργικές απαιτήσεις, η άμεση
+πρόσβαση του υπερ-επόπτη τύπου 1 στο υλικό συμβάλλει στην επίτευξη της
 ικανοποίησης αυτών των δύο απαιτήσεων. Από την άλλη, ένας υπερ-επόπτης τύπου 2
 δεν έρχεται σε αντιπαράθεση με το υποκείμενο ΛΣ και επιτρέπει την χρήση
 προγραμμάτων και οδηγών που το ΛΣ αυτό πιθανόν να μην είναι σε θέση να
 εκτελέσει.
 
 Η εικονικοποίηση διακομιστών χωρίζεται σε δύο κατηγορίες βάσει της μεθόδου
-επίτευξης της. Την πλήρη εικονικοποίηση και την παρα-εικονικοποίηση
-\cite{abacusFullParaOSVirtualization}. Στην πρώτη περίπτωση το λειτουργικό
-σύστημα που εκτελείται στον εικονικό διακομιστή συμπεριφέρεται όπως θα
-συμπεριφερόταν σε έναν φυσικό διακομιστή. Αυτό συμβαίνει διότι από μεριάς του
-λειτουργικού συστήματος δεν υπάρχει επίγνωση της εικονικοποίησης που έχει λάβει
-μέρος για να δημιουργηθούν οι εικονικοί πόροι στους οποίους στεγάζεται. Η
-πλήρης εικονικοποίηση μπορεί να είναι δύο ειδών. Υποβοηθούμενη από το λογισμικό
-ή από το υλικό. Στο πρώτο είδος, πραγματοποιείται εικονικοποίηση ολόκληρου του
-υλικού μέσω του υπερ-επόπτη (τύπου 2) που εκτελείται στο ΛΣ. Στο δεύτερο είδος,
-όπου δεν υπάρχει ΛΣ, δύναται το λειτουργικό σύστημα του εικονικού διακομιστή να
-κάνει χρήση της φυσικής κεντρικής μονάδας επεξεργασίας του διακομιστή
-φιλοξενίας εάν αυτή το υποστηρίζει
-\cite{geeksforgeeksHardwareAssistedVirtualization}. Στην περίπτωση της
-παρα-εικονικοποίησης το λειτουργικό σύστημα αναγνωρίζει την ύπαρξη του
-υπερ-επόπτη και απαιτείται η τροποποίηση και των δύο ώστε να μπορούν να
-επικοινωνούν με χρήση υπερ-κλήσεων. Αν και το γεγονός αυτό μειώνει την
+επίτευξης της: την πλήρη εικονικοποίηση (full virtualization) και την
+παρα-εικονικοποίηση \cite{abacusFullParaOSVirtualization} (paravirtualization).
+Στην πρώτη περίπτωση το λειτουργικό σύστημα που εκτελείται στον εικονικό
+διακομιστή συμπεριφέρεται όπως θα συμπεριφερόταν σε έναν φυσικό διακομιστή.
+Αυτό συμβαίνει διότι από μεριάς του λειτουργικού συστήματος δεν υπάρχει
+επίγνωση της εικονικοποίησης που έχει λάβει μέρος για να δημιουργηθούν οι
+εικονικοί πόροι στους οποίους στεγάζεται. Η πλήρης εικονικοποίηση μπορεί να
+είναι δύο ειδών: υποβοηθούμενη από το λογισμικό (software-assisted) ή από το
+υλικό (hardware assisted). Στο πρώτο είδος, πραγματοποιείται εικονικοποίηση
+ολόκληρου του υλικού μέσω του υπερ-επόπτη (τύπου 2) που εκτελείται στο ΛΣ. Στο
+δεύτερο είδος, όπου δεν υπάρχει ΛΣ, δύναται το λειτουργικό σύστημα του
+εικονικού διακομιστή να κάνει χρήση της φυσικής κεντρικής μονάδας επεξεργασίας
+του διακομιστή φιλοξενίας εάν αυτή το υποστηρίζει
+\cite{geeksforgeeksHardwareAssistedVirtualization}.
+
+Στην περίπτωση της παρα-εικονικοποίησης το λειτουργικό σύστημα αναγνωρίζει την
+ύπαρξη του υπερ-επόπτη και απαιτείται η τροποποίηση και των δύο ώστε να μπορούν
+να επικοινωνούν με χρήση υπερ-κλήσεων. Αν και το γεγονός αυτό μειώνει την
 συμβατότητα σε σχέση με την πλήρη εικονικοποίηση, η άμεση πρόσβαση στο
-υποκείμενο φυσικό υλικό συμβάλλει στην αύξηση της αποδοτικότητας.
+υποκείμενο φυσικό υλικό συμβάλλει στην αύξηση της αποδοτικότητας - αυτό
+επιτυγχάνεται κυρίως για ορισμένα είδη πόρων.
 
 \subsection{Ορισμός Εικονικοποίησης} \label{virtualizationDefinition}
 
@@ -314,7 +325,7 @@ portal), ενός εργαλείου γραμμής εντολών ή άμεσα
 μηχάνημα φιλοξενίας (hosting machine), ενώ οι πολλές εικονικές μηχανές που
 χρησιμοποιούν τους πόρους του είναι οι επισκέπτες (guests) ή αλλιώς τα
 φιλοξενούμενα μηχανήματα (hosted machines). Οι επισκέπτες, αντιμετωπίζουν τους
-υπολογιστικούς πόρους όπως είναι η κεντρική μονάδα επεξεργασίας, η μνήμη και ο
+υπολογιστικούς πόρους, όπως είναι η κεντρική μονάδα επεξεργασίας, η μνήμη και ο
 αποθηκευτικός χώρος, ως μια δεξαμενή πόρων που μπορεί εύκολα να ανακατανεμηθεί.
 Οι χειριστές (operators) μπορούν να ελέγχουν εικονικά στιγμιότυπα αυτών των
 πόρων, ούτως ώστε να πραγματοποιούν οριζόντια ή κάθετη κλιμάκωση. Δηλαδή είτε
@@ -326,32 +337,33 @@ portal), ενός εργαλείου γραμμής εντολών ή άμεσα
 (Τεχνολογίας Πληροφοριών) χρησιμοποιώντας πόρους στους οποίους παραδοσιακά
 μπορούσαμε να έχουμε πρόσβαση μονάχα με την ιδιοκτησία φυσικών μηχανημάτων. Μας
 επιτρέπει να αξιοποιήσουμε όλες τις δυνατότητες ενός φυσικού μηχανήματος
-διανέμοντας τις σε πολλούς χρήστες και περιβάλλοντα. Με άλλα λόγια,
+διανέμοντάς τις σε πολλούς χρήστες και περιβάλλοντα. Με άλλα λόγια,
 υποστηρίζεται η πολλαπλή μίσθωση ανά φυσικό μηχάνημα με τη μορφή εικονικών
 μηχανών καθώς και η αυξημένη χρήση πόρων των φυσικών μηχανών (στα κέντρα
 δεδομένων του νέφους).
 
 Με βάση ένα παράδειγμα της Red Hat \cite{redhatVirtualization}, ας φανταστούμε
-πως έχουμε τρεις διακομιστές (servers) (δηλ. φυσικά μηχανήματα), στον καθένα
-από τους οποίους έχει ανατεθεί ένας συγκεκριμένος σκοπός. Ένας διακομιστής
-ηλεκτρονικού ταχυδρομείου (email server), ένας διακομιστής ιστού (web server)
-και ένας που εκτελεί εσωτερικές εταιρικές εφαρμογές κληρονομιάς, οι οποίες
-σταμάτησαν να διατηρούνται αλλά είναι ακόμα λειτουργικές. Στο συγκεκριμένο
-παράδειγμα κάθε ένας από τους διακομιστές χρησιμοποιεί μονάχα το 30\% των
-δυνατοτήτων του (ως προς τους πόρους που μπορεί να διαθέσει).
+πως έχουμε τρεις φυσικούς διακομιστές (servers) (δηλ. φυσικά μηχανήματα), στον
+καθένα από τους οποίους φιλοξενείται ένα συγκεκριμένο συστατικό (component)
+(λογισμικού): ένας διακομιστής ηλεκτρονικού ταχυδρομείου (email server), ένας
+διακομιστής ιστού (web server) και ένας διακομιστής που εκτελεί εσωτερικές
+εταιρικές εφαρμογές κληρονομιάς (οι οποίες σταμάτησαν να διατηρούνται αλλά
+είναι ακόμα λειτουργικές), αντίστοιχα. Στο συγκεκριμένο παράδειγμα κάθε ένας
+από τους (φυσικούς) διακομιστές χρησιμοποιεί μονάχα το 30\% των δυνατοτήτων του
+(ως προς τους πόρους που μπορεί να διαθέσει).
 
 \begin{center}
 \begin{figure}[!ht]
 \centering
-    \includegraphics[width = .95\textwidth]{Figures/RedHat_Virtualization/redhat_virtualization_server_usage1.png}
+    \includegraphics[width = .9\textwidth]{Figures/RedHat_Virtualization/redhat_virtualization_server_usage1.png}
     \captionof{figure}{Χρήση διακομιστών χωρίς εικονικοποίηση \cite{redhatVirtualization}}
     \label{fig:virtualizationServerUsage1}
 \end{figure}
 \vspace*{-30pt}
 \end{center}
 
-Παραδοσιακά, αυτή η αρχιτεκτονική όπου εκτελούνται μεμονωμένες εργασίες έκαστη
-αποκλειστικά σε συγκεκριμένο διακομιστή ήταν ευκολότερη και πιο αξιόπιστη αλλά
+Παραδοσιακά, αυτή η αρχιτεκτονική, όπου εκτελούνται μεμονωμένες εργασίες έκαστη
+αποκλειστικά σε συγκεκριμένο διακομιστή, ήταν ευκολότερη και πιο αξιόπιστη αλλά
 δεν παύει να είναι και η λιγότερο αποδοτική λύση. Με την άφιξη της τεχνολογίας
 της εικονικοποίησης όμως, είναι πλέον εφικτό να χωριστεί ένας διακομιστής σε
 περισσότερα μέρη, έχοντας δύο ή παραπάνω εικονικές μηχανές με τη χρήση μιας
@@ -360,7 +372,7 @@ portal), ενός εργαλείου γραμμής εντολών ή άμεσα
 \begin{center}
 \begin{figure}[!ht]
 \centering
-    \includegraphics[width = .95\textwidth]{Figures/RedHat_Virtualization/redhat_virtualization_server_usage2.png}
+    \includegraphics[width = .9\textwidth]{Figures/RedHat_Virtualization/redhat_virtualization_server_usage2.png}
     \captionof{figure}{Χρήση διακομιστών με εικονικοποίηση \cite{redhatVirtualization}}
     \label{fig:virtualizationServerUsage2}
 \end{figure}
@@ -371,9 +383,9 @@ portal), ενός εργαλείου γραμμής εντολών ή άμεσα
 αυξηθεί ραγδαία η αξιοποίηση των δυνατοτήτων του. Με βάση το προηγούμενο
 παράδειγμα, αν μια εικονική μηχανή λαμβάνει το 30\% των πόρων ενός
 διακομιστή/φυσικού μηχανήματος, τότε ορισμένες από τις προαναφερόμενες
-λειτουργικότητες (παροχής υπηρεσιών ιστού, ηλεκτρονικού ταχυδρομείου και
-εφαρμογών) θα μπορούσαν να εγκατασταθούν στον ίδιο διακομιστή με την μορφή
-εικονικών μηχανών.
+λειτουργικότητες/συστατικά λογισμικού (παροχής υπηρεσιών ιστού, ηλεκτρονικού
+ταχυδρομείου και εφαρμογών) θα μπορούσαν να εγκατασταθούν στον ίδιο διακομιστή
+με την μορφή εικονικών μηχανών.
 
 Αφού η δημιουργία και καταστροφή των εικονικών μηχανών σε ένα μηχάνημα
 πραγματοποιείται δυναμικά ανάλογα με τη ζήτηση, αυτό σημαίνει πως ένας
@@ -392,16 +404,16 @@ off). Το τελευταίο είναι χρήσιμο κυρίως όταν η
 την έκαναν πραγματικότητα, όπως οι υπερ-επόπτες, αναπτύχθηκαν πριν από
 δεκαετίες για να δώσουν σε πολλούς χρήστες ταυτόχρονη πρόσβαση σε υπολογιστές
 που επεξεργαζόντουσαν πολλά δεδομένα ταυτόχρονα. Κάτι ιδιαίτερα δημοφιλές στον
-τομέα των επιχειρήσεων για καθήκοντα ρουτίνας που έπρεπε να εκτελεστούν
-χιλιάδες φορές και πολύ γρήγορα όπως η μισθοδοσία υπαλλήλων.
+τομέα των επιχειρήσεων για καθήκοντα ρουτίνας (routine tasks) που έπρεπε να
+εκτελεστούν χιλιάδες φορές και πολύ γρήγορα όπως η μισθοδοσία υπαλλήλων.
 
 Ωστόσο, μέσα στις επόμενες δεκαετίες, ήρθαν στο προσκήνιο άλλες λύσεις στο
 πρόβλημα διαμοιρασμού ενός μηχανήματος σε πολλούς χρήστες, μειώνοντας έτσι το
 ενδιαφέρον για την τεχνολογία εικονικοποίησης. Μία από αυτές ήταν ο
-διαμοιρασμός χρόνου (time-sharing) όπου ένας χρήστης μπορούσε να χρησιμοποιεί
+διαμοιρασμός χρόνου (time-sharing), όπου ένας χρήστης μπορούσε να χρησιμοποιεί
 το λειτουργικό σύστημα απομονωμένα από τους υπόλοιπους. Κάτι που οδήγησε στη
 δημιουργία λειτουργικών συστημάτων όπως το UNIX, το οποίο με τη σειρά του
-άνοιξε δρόμο για την άφιξη του Linux. Καθ' όλη τη διάρκεια αυτή, η
+άνοιξε το δρόμο για την άφιξη του Linux. Καθ' όλη τη διάρκεια αυτή, η
 εικονικοποίηση παρέμεινε σε μεγάλο βαθμό μη διαδεδομένη.
 
 Προχωρώντας στη δεκαετία του 1990, οι περισσότερες επιχειρήσεις διέθεταν
@@ -417,9 +429,9 @@ off). Το τελευταίο είναι χρήσιμο κυρίως όταν η
 εικονικοποίησης και να ανεβαίνει η δημοτικότητά της. Οι εταιρείες μπορούσαν
 πλέον να διαμερίσουν τους διακομιστές τους και να εκτελούν ακόμα και τις
 παλαιές τους εφαρμογές σε πολλούς τύπους και εκδόσεις λειτουργικών συστημάτων.
-Οι διακομιστές άρχισαν να χρησιμοποιούνται πιο αποδοτικά ή και καθόλου,
-μειώνοντας το απαιτούμενο κόστος αγοράς, εγκατάστασης, συντήρησης και ψύξης
-τους.
+Οι διακομιστές άρχισαν να χρησιμοποιούνται πιο αποδοτικά ή και καθόλου (όταν η
+ζήτηση ήταν ελάχιστη), μειώνοντας το απαιτούμενο κόστος αγοράς, εγκατάστασης,
+συντήρησης και ψύξης τους.
 
 Η ευρεία εφαρμογή της εικονικοποίησης συνέβαλε στη μείωση του εγκλωβισμού σε
 έναν μόνο προμηθευτή και την κατέστησε το θεμέλιο του υπολογιστικού νέφους.
@@ -429,9 +441,9 @@ off). Το τελευταίο είναι χρήσιμο κυρίως όταν η
 δρώμενα μιας επιχείρησης. Πρόκειται για ένα λογισμικό το οποίο διασυνδέεται με
 εικονικά περιβάλλοντα και το υποκείμενο φυσικό υλικό τους με απώτερο σκοπό την
 απλοποίηση της διαχείρισης πόρων, τη βελτίωση της ανάλυσης δεδομένων και τον
-εξορθολογισμό των λειτουργιών τους. Ουσιαστικά ένα λογισμικό που συνδέεται
-απομακρυσμένα με υπερ-επόπτες, προσφέροντας μια φιλική προς τον χρήση διεπαφή
-και επιπρόσθετες λειτουργίες όπως η συγκρότηση αναφορών χρήσης, η
+εξορθολογισμό των λειτουργιών τους. Ουσιαστικά, αποτελεί ένα λογισμικό που
+συνδέεται απομακρυσμένα με υπερ-επόπτες, προσφέροντας μια φιλική προς τον χρήση
+διεπαφή και επιπρόσθετες λειτουργίες, όπως η συγκρότηση αναφορών χρήσης, η
 αυτοματοποίηση επιβολής κανόνων και η παρακολούθηση χρήσης εικονικών
 περιβαλλόντων.
 
@@ -451,7 +463,7 @@ off). Το τελευταίο είναι χρήσιμο κυρίως όταν η
 αντιπροσωπεύουν προσομοιώσεις φυσικών υπολογιστών.
 
 Οι υπερ-επόπτες είναι υπεύθυνοι για τη διαχείριση των εικονικών μηχανών
-χωρίζοντας τις και αναθέτοντας σε κάθε μια ένα κομμάτι της διαθέσιμης
+χωρίζοντάς τις και αναθέτοντας σε κάθε μια ένα κομμάτι της διαθέσιμης
 υπολογιστικής ισχύος, μνήμης και χώρου αποθήκευσης. Αυτή η διαδικασία τις
 αποτρέπει από την αλληλεπίδραση μεταξύ τους. Μάλιστα, στην περίπτωση
 κατάρρευσης μιας εικονικής μηχανής, οι υπόλοιπες παραμένουν ανεπηρέαστες.
@@ -491,22 +503,22 @@ off). Το τελευταίο είναι χρήσιμο κυρίως όταν η
 
 \end{itemize}
 
-Αντίθετα, οι υπερ-επόπτες τύπου 2 είναι καταλληλότεροι για μεμονωμένους
-τελικούς χρήστες υπολογιστών που έχουν την ανάγκη να εκτελέσουν πολλαπλά
-λειτουργικά συστήματα (σε έναν υπολογιστή). Παραδείγματα τέτοιων χρηστών είναι
-μηχανικοί, επαγγελματίες ασφαλείας που αναλύουν κακόβουλο λογισμικό και
-υπάλληλοι επιχειρήσεων που χρειάζονται πρόσβαση σε εφαρμογές που είναι
-διαθέσιμες αποκλειστικά σε διαφορετικές πλατφόρμες λογισμικού από τη δική τους.
-Διατίθενται συχνά πρόσθετες εργαλειοθήκες για τους χρήστες, οι οποίες μπορούν
-να εγκατασταθούν στο λειτουργικό σύστημα προκειμένου να παρέχουν βελτιωμένες
-συνδέσεις μεταξύ του υποκείμενου λειτουργικού συστήματος και εκείνου της
-εικονικής μηχανής. Οι πρόσθετες δυνατότητες που υποστηρίζονται μετά την
-παραπάνω διαδικασία μπορεί να είναι η αποκοπή και επικόλληση μεταξύ των δύο
-συστημάτων ή η κοινή πρόσβαση στον αποθηκευτικό χώρο. Η τρέχουσα προσέγγιση
-επιτρέπει τη γρήγορη εναλλαγή σε διαφορετικά λειτουργικά συστήματα πέραν του
-ήδη υπάρχοντος, πράγμα που αυξάνει την παραγωγικότητα του τελικού χρήστη, αφού
-μπορεί να έχει πρόσβαση σε εργαλεία που δεν υποστηρίζονται στο δικό του
-(αρχικό/υπάρχον σύστημα).
+Από την άλλη μεριά, οι υπερ-επόπτες τύπου 2 είναι καταλληλότεροι για
+μεμονωμένους τελικούς χρήστες υπολογιστών που έχουν την ανάγκη να εκτελέσουν
+πολλαπλά λειτουργικά συστήματα (σε έναν υπολογιστή). Παραδείγματα τέτοιων
+χρηστών είναι μηχανικοί, επαγγελματίες ασφαλείας που αναλύουν κακόβουλο
+λογισμικό και υπάλληλοι επιχειρήσεων που χρειάζονται πρόσβαση σε εφαρμογές που
+είναι διαθέσιμες αποκλειστικά σε διαφορετικές πλατφόρμες λογισμικού από τη δική
+τους. Διατίθενται συχνά πρόσθετες εργαλειοθήκες για τους χρήστες, οι οποίες
+μπορούν να εγκατασταθούν στο υποκείμενο λειτουργικό σύστημα προκειμένου να
+παρέχουν βελτιωμένες συνδέσεις μεταξύ του υποκείμενου λειτουργικού συστήματος
+και εκείνου της εικονικής μηχανής. Οι πρόσθετες δυνατότητες που υποστηρίζονται
+μετά την παραπάνω διαδικασία μπορεί να είναι η αποκοπή και επικόλληση μεταξύ
+των δύο συστημάτων ή η κοινή πρόσβαση στον αποθηκευτικό χώρο. Η τρέχουσα
+προσέγγιση επιτρέπει τη γρήγορη εναλλαγή σε διαφορετικά λειτουργικά συστήματα
+πέραν του ήδη υπάρχοντος, πράγμα που αυξάνει την παραγωγικότητα του τελικού
+χρήστη, αφού μπορεί να έχει πρόσβαση σε εργαλεία που δεν υποστηρίζονται στο
+δικό του (αρχικό/υπάρχον σύστημα).
 
 Σε κάθε τύπο υπερ-επόπτη, όταν το φιλοξενούμενο ΛΣ αιτηθεί πρόσβαση στους
 πόρους υπολογισμού, μνήμης και δικτύου του φυσικού υλικού, όλες οι προσβάσεις
@@ -520,14 +532,14 @@ off). Το τελευταίο είναι χρήσιμο κυρίως όταν η
 ΛΣ φιλοξενίας. Επιπροσθέτως, εισάγεται πιθανός κίνδυνος ασφαλείας εάν ένας
 εισβολέας παραβιάσει το κεντρικό λειτουργικό σύστημα, επειδή θα μπορούσε στη
 συνέχεια να χειραγωγήσει οποιοδήποτε φιλοξενούμενο λειτουργικό σύστημα
-εκτελείται σε αυτόν.
+εκτελείται σε αυτό.
 
 \subsection{Χαρακτηριστικά ενός υπερ-επόπτη}  \label{hypervisorCharacteristics}
 
 Αν και υπάρχουν διαφορετικά είδη υπερ-εποπτών, όλοι έχουν κάποια χαρακτηριστικά
 που πρέπει να λάβει κανείς υπόψιν όταν επιλέγει ποιον θα χρησιμοποιήσει. Μερικά
-σημαντικά αυτών όπως αναφέρονται από την \citeauthor{ibmHypervisorDefinition}
-\cite{ibmHypervisorDefinition} είναι:
+σημαντικά αυτών, όπως αναφέρονται από την \citeauthor{ibmHypervisorDefinition}
+\cite{ibmHypervisorDefinition}, είναι:
 
 \begin{itemize}
 
@@ -543,7 +555,7 @@ off). Το τελευταίο είναι χρήσιμο κυρίως όταν η
 
         Για τη διαχείριση ενός υπερ-επόπτη σε διάφορες κλίμακες πρέπει να
         υπάρχει καλή τεκμηρίωση και διάφορα εργαλεία είτε επίσημα είτε από την
-        κοινότητα που να επιτρέπουν δυνατότητες όπως δημιουργία αντιγράφων
+        κοινότητα που να επιτρέπουν δυνατότητες, όπως δημιουργία αντιγράφων
         ασφαλείας, ανάλυση χωρητικότητας και διαχείριση εναλλαγής εικονικών
         μηχανών \cite{vmfailover} με αντίγραφα τους σε περιπτώσεις σφάλματος
         του λειτουργικού συστήματος της εκτελούμενης (εικονικής μηχανής).
@@ -570,8 +582,8 @@ off). Το τελευταίο είναι χρήσιμο κυρίως όταν η
         Το κόστος είναι ένας παράγοντας που πρέπει να ληφθεί υπόψιν κατά την
         επιλογή ενός υπερ-επόπτη. Οι περισσότεροι είναι δωρεάν αλλά υπάρχουν
         και εμπορικές εκδόσεις που προσφέρουν περισσότερες δυνατότητες. Για
-        παράδειγμα, η ύπαρξη ή μη, λογισμικού διαχείρισής τους που να επιτρέπει
-        την εύκολη κλιμάκωση με βάση τις απαιτήσεις της επιχείρησης.
+        παράδειγμα, μπορεί να προσφέρεται λογισμικό διαχείρισής τους που να
+        επιτρέπει την εύκολη κλιμάκωση με βάση τις απαιτήσεις της επιχείρησης.
 
 \end{itemize}
 
@@ -585,11 +597,11 @@ off). Το τελευταίο είναι χρήσιμο κυρίως όταν η
 Η επιλογή του τύπου υπερ-επόπτη που θα χρησιμοποιηθεί είναι άμεσα εξαρτώμενη
 από τις ανάγκες του κάθε τελικού χρήση ή επιχείρησης ζυγίζοντας τα
 πλεονεκτήματα και μειονεκτήματα που έρχονται με την κάθε επιλογή. Παραδείγματος
-χάριν, αν η ταχύτητα και η απόδοση αποτελούν χαρακτηριστικά υψίστης σημασίας,
-τότε η επιλογή υπερ-επόπτη τύπου 1 αποτελεί μονόδρομο. Από την άλλη, αν η
-προτεραιότητα είναι η ευκολία διαχείρισης και η ευελιξία ταχείας εναλλαγής σε
-διαφορετικά λειτουργικά συστήματα, η πιο ταιριαστή επιλογή είναι ένας
-υπερ-επόπτης τύπου 2.
+χάριν, αν η ταχύτητα και η απόδοση θεωρούνται από τον χρήστη χαρακτηριστικά
+υψίστης σημασίας, τότε η επιλογή υπερ-επόπτη τύπου 1 αποτελεί μονόδρομο. Από
+την άλλη, αν η προτεραιότητα είναι η ευκολία διαχείρισης και η ευελιξία ταχείας
+εναλλαγής σε διαφορετικά λειτουργικά συστήματα, η πιο ταιριαστή επιλογή είναι
+ένας υπερ-επόπτης τύπου 2.
 
 \section {Τρόπος λειτουργίας της εικονικοποίησης} \label{virtualizationOperation}
 
@@ -639,9 +651,9 @@ off). Το τελευταίο είναι χρήσιμο κυρίως όταν η
 
 \subsection{Είδη εικονικοποίησης} \label{virtualizationImplementations}
 
-Υπάρχουν πολλά είδη εικονικοποίησης. Πέντε βασικά αυτών όπως αναφέρονται από
-την Red Hat \cite{redhatVirtualization} και τρία ακόμα που χρησιμοποιούνται
-συχνά είναι τα παρακάτω:
+Υπάρχουν πολλά είδη εικονικοποίησης. Πέντε βασικά αυτών, όπως αναφέρονται από
+την Red Hat \cite{redhatVirtualization}, συνδυαστικά με τρία ακόμα που
+χρησιμοποιούνται συχνά είναι τα παρακάτω:
 
 \begin{itemize}
 
@@ -751,15 +763,15 @@ off). Το τελευταίο είναι χρήσιμο κυρίως όταν η
 
 \end{itemize}
 
-Η εικονικοποίηση λειτουργικού συστήματος είναι κάτι που συμβαίνει στον πυρήνα.
-Αποτελεί υποκατηγορία της εικονικοποίησης διακομιστών και πραγματοποιείται σε
-επίπεδο λειτουργικού συστήματος. Ουσιαστικά αναφερόμαστε στην διαδικασία της
-δοχειοποίησης και συγκεκριμένα, την δοχειοποίηση λειτουργικών συστημάτων. Κατά
-την χρήση της, μπορούν να εκτελεστούν ταυτοχρόνως πολλαπλά λειτουργικά
-συστήματα μέσα σε απομονωμένα εικονικά περιβάλλοντα, όπου το κάθε ένα από αυτά
-μοιράζεται τον ίδιο πυρήνα με το λειτουργικό σύστημα φιλοξενίας. Μεγαλύτερη
-ανάλυση της εικονικοποίησης σε επίπεδο λειτουργικού συστήματος πραγματοποιήθηκε
-στο \ref{osVirtualization}.
+Η εικονικοποίηση λειτουργικού συστήματος είναι κάτι που συμβαίνει στον πυρήνα
+(ΛΣ). Αποτελεί υποκατηγορία της εικονικοποίησης διακομιστών και
+πραγματοποιείται σε επίπεδο λειτουργικού συστήματος. Ουσιαστικά αναφερόμαστε
+στην διαδικασία της δοχειοποίησης και συγκεκριμένα, την δοχειοποίηση
+λειτουργικών συστημάτων. Κατά την χρήση της, μπορούν να εκτελεστούν ταυτοχρόνως
+πολλαπλά λειτουργικά συστήματα μέσα σε απομονωμένα εικονικά περιβάλλοντα, όπου
+το κάθε ένα από αυτά μοιράζεται τον ίδιο πυρήνα με το λειτουργικό σύστημα
+φιλοξενίας. Μεγαλύτερη ανάλυση της εικονικοποίησης σε επίπεδο λειτουργικού
+συστήματος πραγματοποιείται στο \ref{osVirtualization}.
 
 \clearpage
 
@@ -915,17 +927,17 @@ servers). Το αποτέλεσμα αυτού, ήταν η απόκτηση τ
 
     \item \textbf{Αποδοτικότητα πόρων}:
 
-        Η χρήση εικονικοποίησης συνεπάγεται με την μείωση του αριθμού των
-        φυσικών μηχανημάτων που απαιτούνται για την εκτέλεση των εφαρμογών.
-        Αυτό συμβαίνει διότι εφόσον ένας φυσικός διακομιστής μπορεί να
-        φιλοξενήσει πολλαπλές εικονικές μηχανές, αυτές με την σειρά τους
-        δύναται να αντικαταστήσουν άλλους φυσικούς διακομιστές που θα ήταν
-        απαραίτητοι για την εκτέλεση διαφορετικών λειτουργιών
-        \cite{mediumVirtualization}. Με αυτόν τον τρόπο, εξοικονομείται η
-        ενέργεια που θα απαιτούσε η διάθεση των υπολογιστικών πόρων των φυσικών
-        μηχανημάτων που αποσύρθηκαν, ενώ ταυτόχρονα αξιοποιούνται σε μεγαλύτερο
-        βαθμό οι υπολογιστικοί πόροι του μηχανήματος που φιλοξενεί τις
-        εικονικές μηχανές.
+        Η χρήση εικονικοποίησης συνεπάγεται την μείωση του αριθμού των φυσικών
+        μηχανημάτων που απαιτούνται για την εκτέλεση των εφαρμογών. Αυτό
+        συμβαίνει διότι εφόσον ένας φυσικός διακομιστής μπορεί να φιλοξενήσει
+        πολλαπλές εικονικές μηχανές, αυτές με την σειρά τους δύναται να
+        αντικαταστήσουν άλλους φυσικούς διακομιστές που θα ήταν απαραίτητοι για
+        την εκτέλεση διαφορετικών λειτουργιών \cite{mediumVirtualization}. Με
+        αυτόν τον τρόπο, εξοικονομείται η ενέργεια που θα απαιτούσε η διάθεση
+        των (έξτρα) υπολογιστικών πόρων των φυσικών μηχανημάτων που
+        αποσύρθηκαν, ενώ ταυτόχρονα αξιοποιούνται σε μεγαλύτερο βαθμό οι
+        υπολογιστικοί πόροι του μηχανήματος που φιλοξενεί τις εικονικές
+        μηχανές.
 
     \item \textbf{Ευκολότερη διαχείριση}:
 
@@ -934,10 +946,10 @@ servers). Το αποτέλεσμα αυτού, ήταν η απόκτηση τ
         εργασιών. Οι διαχειριστές συστημάτων μπορούν να χρησιμοποιούν εργαλεία
         για τον καθορισμό εικονικών μηχανών χρησιμοποιώντας πρότυπα κατάλληλα
         για την υποδομή κάθε επιχείρησης. Με αυτόν τον τρόπο, η εγκατάσταση και
-        η ρύθμισή τους μπορεί να γίνεται επανειλημμένα με αυτοματοποιημένο
-        τρόπο δίχως το ρίσκο ανθρώπινου λάθους και γλιτώνοντας τον χρόνο
-        εγκατάστασης και ρύθμισής τους χειροκίνητα. Ένας συνδυασμός εργαλείων
-        που κάνει αυτή τη διαδικασία πραγματικότητα είναι τα Ansible
+        η ρύθμιση των εικονικών μηχανών μπορεί να γίνεται επανειλημμένα με
+        αυτοματοποιημένο τρόπο δίχως το ρίσκο ανθρώπινου λάθους και γλιτώνοντας
+        τον χρόνο εγκατάστασης και ρύθμισής τους χειροκίνητα. Ένας συνδυασμός
+        εργαλείων που κάνει αυτή τη διαδικασία πραγματικότητα είναι τα Ansible
         \footfullcite{ansible} και Terraform \footfullcite{terraform}.
 
     \item \textbf{Ελάχιστος χρόνος διακοπής λειτουργίας}:
@@ -946,9 +958,9 @@ servers). Το αποτέλεσμα αυτού, ήταν η απόκτηση τ
         προκαλέσουν διακοπή λειτουργίας και να διαταράξουν την παραγωγικότητα
         των χρηστών. Οι διαχειριστές έχουν την δυνατότητα εκτέλεσης
         πλεοναζουσών εικονικών μηχανών, με σκοπό την ταχεία εναλλαγή σε αυτές
-        στην περίπτωση που προκύψουν προβλήματα στις αρχικές. Κάτι τέτοιο, δεν
-        θα ήταν αποδοτικό για την επιχείρηση διαθέτοντας αποκλειστικά μη
-        εικονικοποιημένα φυσικά μηχανήματα.
+        στην περίπτωση που προκύψουν προβλήματα στις αρχικές (που έχουν
+        διατεθεί). Κάτι τέτοιο, δεν θα ήταν αποδοτικό για την επιχείρηση
+        διαθέτοντας αποκλειστικά μη εικονικοποιημένα φυσικά μηχανήματα.
 
     \item \textbf{Ταχύτερη παροχή}:
 
@@ -968,7 +980,7 @@ servers). Το αποτέλεσμα αυτού, ήταν η απόκτηση τ
 υπερ-επόπτες που μπορεί να διαφέρουν όχι μόνο στα χαρακτηριστικά τους αλλά και
 στις διάφορες τεχνικές που χρησιμοποιούν για να κάνουν την εικονικοποίηση
 πραγματικότητα. Μια από αυτές ονομάζεται παρα-εικονικοποίηση
-(para-virtualization) \cite{suseParavirtualizationDefinition}.
+(paravirtualization) \cite{suseParavirtualizationDefinition}.
 
 Κάθε εικονική μηχανή απαιτεί ένα συγκεκριμένο ποσοστό χρήσης υπολογιστικών
 πόρων του φυσικού διακομιστή για να εκτελείται. Μέσα σε αυτό το ποσοστό,
@@ -1033,7 +1045,7 @@ API, ώστε να μπορεί να κάνει χρήση των υπερ-κλ
 
 \clearpage
 
-Αντιθέτως, στo Σχήμα \ref{fig:ParaVirtualization} όπου και φαίνεται η
+Αντιθέτως, στο Σχήμα \ref{fig:ParaVirtualization} όπου και φαίνεται η
 αρχιτεκτονική της παρα-εικονικοποίησης, βλέπουμε πως μέσω των υπερ-κλήσεων, όλα
 τα αιτήματα προορίζονται στη στρώση εικονικοποίησης και από εκεί στο κύριο
 σύστημα (χωρίς την ανάγκη κάποιας επεξεργασίας ή μετάφρασης).
@@ -1087,8 +1099,8 @@ API, ώστε να μπορεί να κάνει χρήση των υπερ-κλ
 
 3 &
 
-Χρήση δυαδικής μετάφρασης.\footnote{\textgreek{Αυτό ισχύει στην περίπτωση
-εικονικοποίησης υποβοηθούμενη από το λογισμικό.}} &
+Χρήση δυαδικής μετάφρασης\footnote{\textgreek{Αυτό ισχύει στην περίπτωση
+εικονικοποίησης υποβοηθούμενη από το λογισμικό.}}. &
 
 Χρήση υπερ-κλήσεων κατά την εκτέλεση. \\
 
@@ -1096,11 +1108,11 @@ API, ώστε να μπορεί να κάνει χρήση των υπερ-κλ
 
 4 &
 
-Πιο αργές ταχύτητες
-\cite{ParavirtualizationVmware}\footnote{\textgreek{Με βάση την VMware,
-η απόδοση της παρα-εικονικοποίησης είναι καλύτερη υπό ορισμένες περιπτώσεις,
-ενώ η πλήρης εικονικοποίηση με χρήση δυαδικής μετάφρασης παρέχει καλύτερη
-απόδοση από την πρώτη γενιά εικονικοποίησης υποβοηθούμενη από το υλικό.}}. &
+Πιο αργές ταχύτητες\footnote{\textgreek{Με βάση την VMware, η απόδοση της
+παρα-εικονικοποίησης είναι καλύτερη υπό ορισμένες περιπτώσεις, ενώ η
+πλήρης εικονικοποίηση με χρήση δυαδικής μετάφρασης παρέχει καλύτερη
+απόδοση από την πρώτη γενιά εικονικοποίησης υποβοηθούμενη από το υλικό.}}
+\cite{ParavirtualizationVmware}. &
 
 Γρηγορότερη εκτέλεση. \\
 
@@ -1110,7 +1122,8 @@ API, ώστε να μπορεί να κάνει χρήση των υπερ-κλ
 
 Μεγαλύτερη συμβατότητα και μεταφερσιμότητα. &
 
-Λόγω της αρχιτεκτονικής της είναι δυσκολότερη η μεταφορά εικονικών μηχανών. \\
+Λόγω της αρχιτεκτονικής της είναι δυσκολότερη η μεταφορά εικονικών μηχανών (από
+έναν φυσικό διακομιστή σε έναν άλλο) \\
 
 \hline
 
@@ -1131,7 +1144,7 @@ API, ώστε να μπορεί να κάνει χρήση των υπερ-κλ
 \section{Ασφάλεια στην εικονικοποίηση} \label{virtualizationSecurity}
 
 Η χρήση της εικονικοποίησης παρέχει αρκετά εγγενή οφέλη ασφαλείας με την μορφή
-μέτρων ανάκαμψης από επιθέσεις. Ένα σημαντικό αυτών, είναι η ικανότητα
+μέτρων ανάκαμψης από επιθέσεις. Ένα σημαντικό εξ αυτών, είναι η ικανότητα
 επαναφοράς εικονικών μηχανών που έχουν μολυνθεί με κακόβουλο λογισμικό σε μια
 χρονική περίοδο πριν τη μόλυνση τους. Αυτό επιτυγχάνεται μέσω της δυνατότητας
 δημιουργίας στιγμιοτύπων εικονικών μηχανών \cite{vmSnapshots}, η οποία
@@ -1241,35 +1254,35 @@ API, ώστε να μπορεί να κάνει χρήση των υπερ-κλ
 \subsubsection{Απειλές για τον πάροχο νέφους μέσω δικτύου} \label{cloudProviderThreatsOverNetwork}
 
 Σήμερα όλο και περισσότερες επιχειρήσεις θα προτιμήσουν να βασιστούν σε έναν
-πάροχο νέφους για την απόκτηση υποδομών προκειμένου να ξεκινήσουν να
-εξυπηρετούν τους δυνητικούς πελάτες τους έναντι της παραδοσιακής διαδικασίας
-αγοράς, ρύθμισης και διαχείρισης φυσικών διακομιστών. Η ταχύτερη εκκίνηση
-παροχής υπηρεσιών, το μικρότερο κόστος και η ευκολία διαχείρισης της υποδομής
-τους, δεν αφήνουν περιθώρια αμφιβολίας της ορθότητας αυτής της απόφασης. Για να
-μπορούν όμως να παρέχουν τις υπηρεσίες τους στους τελικούς χρήστες, είναι
-απαραίτητη η μεταφορά δεδομένων από την επιχείρηση προς τον πάροχο νέφους, στις
-υποδομές του οποίου στεγάζονται οι εφαρμογές τους. Όπως αναφέραμε όμως στο
+πάροχο νέφους για την απόκτηση υποδομών προκειμένου να εξυπηρετούν τους
+δυνητικούς πελάτες τους έναντι της παραδοσιακής διαδικασίας αγοράς, ρύθμισης
+και διαχείρισης φυσικών διακομιστών. Η ταχύτερη εκκίνηση παροχής υπηρεσιών, το
+μικρότερο κόστος και η ευκολία διαχείρισης της υποδομής τους, δεν αφήνουν
+περιθώρια αμφιβολίας της ορθότητας αυτής της απόφασης. Για να μπορούν όμως να
+παρέχουν τις υπηρεσίες τους στους τελικούς χρήστες, είναι απαραίτητη η μεταφορά
+δεδομένων από την επιχείρηση προς τον πάροχο νέφους, στις υποδομές του οποίου
+στεγάζονται οι εφαρμογές τους. Όπως αναφέραμε όμως στο
 \ref{cloudComputingSecurity}, εισάγεται έτσι ένα αναγκαίο μοντέλο εμπιστοσύνης
 ανάμεσα στον πάροχο νέφους και τις επιχειρήσεις. Δηλαδή, ταυτόχρονη εμπιστοσύνη
-ως προς την απουσία μη εξουσιοδοτημένης πρόσβασης σε αυτά από τον πάροχο και ως
-προς την ικανότητα του παρόχου να λάβει τα απαραίτητα μέτρα ασφαλείας για την
-προστασία τους από εξωτερικούς κακόβουλους χρήστες.
+ως προς την απουσία μη εξουσιοδοτημένης πρόσβασης στα δεδομένα των επιχειρήσεων
+από τον πάροχο και ως προς την ικανότητα του παρόχου να λάβει τα απαραίτητα
+μέτρα ασφαλείας για την προστασία τους από εξωτερικούς κακόβουλους χρήστες.
 
 Ένα από τα σημαντικότερα ζητήματα που απασχολεί μια επιχείρηση είναι η
 ασφάλεια. Επιλέγοντας να χρησιμοποιήσουν τις υπηρεσίες ενός παρόχου νέφους,
-όμως, παραχωρούν ουσιαστικά πρόσβαση στις εφαρμογές τους και στα ευαίσθητα
-δεδομένα αυτών, διότι η ευθύνη προστασίας των υποδομών ανήκει στον ιδιοκτήτη
-των υποδομών αυτών και στην προκειμένη περίπτωση αυτός είναι ο πάροχος νέφους.
-Έτσι, κακόβουλοι εισβολείς θα προσπαθήσουν να βρουν τρωτότητες στη διαδικασία
-παράδοσης των υπηρεσιών του παρόχου, τις υπηρεσίες τις ίδιες ή και τις διεπαφές
-με τις οποίες παρέχονται. Ένας συνηθισμένος τρόπος για να γίνει αυτό είναι
-εκτελώντας επιθέσεις τύπου Cross site scripting (XSS), έγχυσης SQL (SQL
-injection), χειραγώγησης cookies ή εκμετάλλευσης μη ασφαλούς ρύθμισης, θέτοντας
-έτσι σε κίνδυνο ευαίσθητες πληροφορίες και δεδομένα των επιχειρήσεων. Επιπλέον,
-επειδή όλα τα δίκτυα είναι επιρρεπή σε επιθέσεις αν δεν έχουν ληφθεί τα
-κατάλληλα μέτρα προστασίας, ένας πάροχος πρέπει να μπορεί να προστατευτεί από
-επιθέσεις όπως η κατασκοπεία και διείσδυση δικτύου (network penetration)
-\cite{arif2015virtualization}.
+όμως, παραχωρούν ουσιαστικά πρόσβαση στον πάροχο αυτό στις εφαρμογές τους και
+στα ευαίσθητα δεδομένα αυτών των εφαρμογών, διότι η ευθύνη προστασίας των
+υποδομών ανήκει στον ιδιοκτήτη των υποδομών αυτών και στην προκειμένη περίπτωση
+αυτός είναι ο πάροχος νέφους. Έτσι, κακόβουλοι εισβολείς θα προσπαθήσουν να
+βρουν τρωτότητες στη διαδικασία παράδοσης των υπηρεσιών του παρόχου, στις
+υπηρεσίες τις ίδιες ή και στις διεπαφές με τις οποίες παρέχονται. Ένας
+συνηθισμένος τρόπος για να γίνει αυτό είναι εκτελώντας επιθέσεις τύπου
+Cross-site scripting (XSS), έγχυσης SQL (SQL injection), χειραγώγησης cookies ή
+εκμετάλλευσης μη ασφαλούς ρύθμισης, θέτοντας έτσι σε κίνδυνο ευαίσθητες
+πληροφορίες και δεδομένα των επιχειρήσεων. Επιπλέον, επειδή όλα τα δίκτυα είναι
+επιρρεπή σε επιθέσεις αν δεν έχουν ληφθεί τα κατάλληλα μέτρα προστασίας, ένας
+πάροχος πρέπει να μπορεί να προστατευτεί από επιθέσεις, όπως η κατασκοπεία και
+διείσδυση δικτύου (network penetration) \cite{arif2015virtualization}.
 
 \subsubsection{Απειλές για τον πάροχο νέφους μέσω εικονικών μηχανών} \label{cloudProviderAttackOverVMs}
 
@@ -1285,8 +1298,8 @@ injection), χειραγώγησης cookies ή εκμετάλλευσης μη
 μπορεί να εξαπλωθούν στο σύστημα μεταπηδώντας από μια εικονική μηχανή στον
 υπερ-επόπτη και από εκεί είτε να συνεχίσουν στο σύστημα είτε να μολύνουν και
 τις υπόλοιπες εικονικές μηχανές που αυτός διαχειρίζεται. Επομένως, ο πάροχος
-απαιτείται να έχει λάβει τα κατάλληλα μέτρα προστασίας έναντι κακόβουλων
-εικονικών μηχανών.
+απαιτείται να έχει λάβει τα κατάλληλα μέτρα προστασίας έναντι μολυσμένων ή
+κακόβουλων εικονικών μηχανών.
 
 Με βάση την ανάλυση που έγινε στο \cite{virtualizationSecurity}, σχετικά με
 απειλές από εικονική μηχανή σε εικονική μηχανή, οι πιο συνηθισμένες είναι η
@@ -1414,7 +1427,8 @@ migration and rollback attacks). Από την άλλη, όσον αφορά τ
 Κατηγοριοποίηση με μεγαλύτερη λεπτομέρεια ως προς τις κατηγορίες αδυναμιών όπου
 δύναται να υπάρχουν τρωτότητες και τις αντιστοιχούμενες αδυναμίες αυτών,
 πραγματοποιήθηκε από τον οργανισμό \citeauthor{enisaSecurityOfVirtualization}
-στο \cite{enisaSecurityOfVirtualization} όπου και απεικονίζεται ως:
+στο \cite{enisaSecurityOfVirtualization} όπου και απεικονίζεται στο ακόλουθο
+σχήμα:
 
 \begin{center}
     \begin{figure}[!ht]
@@ -1442,13 +1456,13 @@ migration and rollback attacks). Από την άλλη, όσον αφορά τ
         Η ακεραιότητα των δεδομένων είναι ένα από τα τρία βασικά στοιχεία της
         ασφάλειας, δίχως την οποία οι επιχειρήσεις δε θα μπορούσαν να
         παραμείνουν λειτουργικές. Αναφέρεται στην προστασία των δεδομένων από
-        μη εξουσιοδοτημένη αλλοίωση καθ' όλη τη διάρκεια της ύπαρξής τους.
-        Δηλαδή είτε βρίσκονται στο στάδιο της μεταφοράς, είτε της αποθήκευσης.
-        Για κάθε επιχείρηση, απαιτείται μεγάλη προσοχή κατά τον σχεδιασμό των
-        βάσεων δεδομένων και της συντήρησής τους σε περιβάλλοντα νέφους αλλά
-        και η χρήση ορθών πρακτικών, όπως ο περιοδικός έλεγχος των δεδομένων
-        για την ανίχνευση πιθανών αλλοιώσεων και η χρήση μηχανισμών αναγνώρισης
-        και αποκατάστασης σφαλμάτων.
+        μη εξουσιοδοτημένη αλλοίωση καθ' όλη τη διάρκεια της ύπαρξής τους, είτε
+        αυτά βρίσκονται στο στάδιο της μεταφοράς, την επεξεργασίας ή της
+        αποθήκευσης. Για κάθε επιχείρηση, απαιτείται μεγάλη προσοχή κατά τον
+        σχεδιασμό των βάσεων δεδομένων και της συντήρησής τους σε περιβάλλοντα
+        νέφους αλλά και η χρήση ορθών πρακτικών, όπως ο περιοδικός έλεγχος των
+        δεδομένων για την ανίχνευση πιθανών αλλοιώσεων και η χρήση μηχανισμών
+        αναγνώρισης και αποκατάστασης σφαλμάτων.
 
     \item \textbf{Εμπιστευτικότητα δεδομένων} \label{dataConfidentiality}
 
@@ -1469,26 +1483,27 @@ migration and rollback attacks). Από την άλλη, όσον αφορά τ
         Η διαθεσιμότητα των δεδομένων, που ολοκληρώνει την τριάδα της
         ασφάλειας, είναι το στοιχείο που εξασφαλίζει πως μια επιχείρηση θα
         μπορεί να παρέχει τις υπηρεσίες της στους τελικούς της χρήστες.
-        Αναφέρεται στην αποφυγή της διακοπής πρόσβασης στα δεδομένα της από
-        εξουσιοδοτημένους φορείς και εξαρτάται άμεσα από τη συνεχή παροχή
-        υπηρεσιών υποδομών προς την επιχείρηση. Η απώλειά της θα είχε ως
-        αποτέλεσμα την διακοπή σημαντικών λειτουργιών της και δυνητικά την
-        μείωση της αξιοπιστίας της. Για να μπορέσει να διασφαλιστεί, πρέπει μια
-        επιχείρηση να έχει προβλέψει για ένα σχέδιο ανάκτησης εφεδρικών
-        αντιγράφων προς αποφυγή της απώλειας σημαντικών δεδομένων της, καθώς
-        και για ένα σχέδιο επαναφοράς των διαδικασιών παροχής τους ώστε να
-        μειώσει στο ελάχιστο την οποιαδήποτε διάρκεια διακοπής των υπηρεσιών
-        της. Τέλος, πρέπει να υπάρχει εμπιστοσύνη προς τον πάροχο νέφους πως
-        δεν θα υπάρξει από μεριάς του απρόσμενη διακοπή της λειτουργίας
-        υποδομών που μπορεί να είναι απαραίτητες για την επιχείρηση.
+        Αναφέρεται στην αποφυγή της διακοπής πρόσβασης στα δεδομένα της
+        επιχείρησης από εξουσιοδοτημένους φορείς και εξαρτάται άμεσα από τη
+        συνεχή παροχή υπηρεσιών υποδομών προς την επιχείρηση. Η απώλεια της
+        διαθεσιμότητας θα είχε ως αποτέλεσμα την διακοπή σημαντικών λειτουργιών
+        της επιχείρησης και δυνητικά την μείωση της αξιοπιστίας της. Για να
+        μπορέσει να διασφαλιστεί, πρέπει μια επιχείρηση να έχει προβλέψει για
+        ένα σχέδιο ανάκτησης εφεδρικών αντιγράφων προς αποφυγή της απώλειας
+        σημαντικών δεδομένων της, καθώς και για ένα σχέδιο επαναφοράς των
+        διαδικασιών παροχής τους ώστε να μειώσει στο ελάχιστο την οποιαδήποτε
+        διάρκεια διακοπής των υπηρεσιών της. Τέλος, πρέπει να υπάρχει
+        εμπιστοσύνη προς τον πάροχο νέφους πως δεν θα υπάρξει από μεριάς του
+        απρόσμενη διακοπή της λειτουργίας υποδομών που μπορεί να είναι
+        απαραίτητες για την επιχείρηση.
 
 \end{itemize}
 
 \subsection{Μέτρα ασφαλείας} \label{securityMeasures}
 
 Προκειμένου να προστατευτεί μια επιχείρηση από τις απειλές που αναφέρθηκαν
-παραπάνω, θα πρέπει να έχει λάβει τα κατάλληλα μέτρα ασφαλείας. Μερικές ορθές
-πρακτικές με βάση τους οργανισμούς
+παραπάνω, θα πρέπει αυτή να έχει λάβει τα κατάλληλα μέτρα ασφαλείας. Μερικές
+ορθές πρακτικές με βάση τους οργανισμούς
 \citeauthor{geeksforgeeksVirtualizationSecurityGoodPractices}
 \cite{geeksforgeeksVirtualizationSecurityGoodPractices} και
 \citeauthor{enisaSecurityOfVirtualization} \cite{enisaSecurityOfVirtualization}
@@ -1508,19 +1523,19 @@ migration and rollback attacks). Από την άλλη, όσον αφορά τ
     \item \textbf{Περιορισμός πρόσβασης στο διαχειριστικό πάνελ του υπερ-επόπτη}:
 
         Η πρόσβαση στον υπερ-επόπτη παρέχει πλήρη έλεγχο στις λειτουργίες του
-        και επομένως, πρέπει να περιορίζεται μόνο σε εξουσιοδοτημένα άτομα.
-        Επιπλέον, οι επιχειρήσεις πρέπει να επιβάλλουν την χρήση πολύπλοκων
-        κωδικών πρόσβασης και να τους αλλάζουν τακτικά, καθώς και την χρήση
-        αυθεντικοποίησης πολλαπλών παραγόντων.
+        και επομένως, πρέπει να περιορίζεται μόνο σε ένα πολύ μικρό αριθμό από
+        εξουσιοδοτημένα άτομα. Επιπλέον, οι επιχειρήσεις πρέπει να επιβάλλουν
+        την χρήση πολύπλοκων κωδικών πρόσβασης και να τους αλλάζουν τακτικά,
+        καθώς και την χρήση αυθεντικοποίησης πολλαπλών παραγόντων.
 
     \item \textbf{Έλεγχος των μηχανημάτων που έχουν πρόσβαση στον υπερ-επόπτη}:
 
         Οι επιχειρήσεις πρέπει να ελέγχουν συχνά ποια μηχανήματα έχουν πρόσβαση
         στον υπερ-επόπτη και να προσθέτουν ή να αφαιρούν μηχανήματα από την
-        λίστα εξουσιοδότησης. Ο συχνός έλεγχος πρόσβασης θα μπορέσει επίσης να
-        αναδείξει προσπάθειες μη εξουσιοδοτημένης πρόσβασης ώστε να ληφθούν τα
-        κατάλληλα μέτρα περιορισμού των ατόμων που επιχειρούν να εισέλθουν σε
-        αυτόν.
+        σχετική λίστα εξουσιοδότησης. Ο συχνός έλεγχος πρόσβασης θα μπορέσει
+        επίσης να αναδείξει προσπάθειες μη εξουσιοδοτημένης πρόσβασης ώστε να
+        ληφθούν τα κατάλληλα μέτρα περιορισμού των ατόμων που επιχειρούν να
+        εισέλθουν στον υπερ-επόπτη.
 
 \clearpage
 
@@ -1553,17 +1568,17 @@ migration and rollback attacks). Από την άλλη, όσον αφορά τ
         Η δικτυακή κίνηση, η μνήμη και οι διεργασίες των εκτελούμενων εικονικών
         μηχανών πρέπει να παρακολουθούνται διαρκώς προκειμένου να ξεχωρίζουν οι
         εικονικές μηχανές που παρουσιάζουν ασυνήθιστες συμπεριφορές. Αυτό θα
-        βοηθήσει στην ορθότερη θέση σε λειτουργία υπαρχόντων μηχανισμών
-        ασφαλείας και ανίχνευσης εισβολών.
+        βοηθήσει στην ορθότερη εκτέλεση υπαρχόντων μηχανισμών ασφαλείας και
+        ανίχνευσης εισβολών.
 
     \item \textbf{Ορθή διαχείριση στιγμιοτύπων εικονικών μηχανών}:
 
         Κάθε στιγμιότυπο μιας εικονικής μηχανής, δύναται να περιέχει ευαίσθητα
-        δεδομένα όπως κωδικοί και προσωπικά δεδομένα χρηστών. Συνεπώς, πρέπει
-        κατά την αποθήκευσή τους να προστατεύονται έναντι μη εξουσιοδοτημένης
-        πρόσβασης, τροποποίησης και αντικατάστασης. Αυτό περιλαμβάνει την ορθή
-        κρυπτογράφησή τους και την διαγραφή όσων στιγμιοτύπων δεν χρειάζονται
-        πλέον.
+        δεδομένα, όπως κωδικοί και προσωπικά δεδομένα χρηστών. Συνεπώς, πρέπει
+        αυτά να προστατεύονται κατά την αποθήκευσή τους έναντι μη
+        εξουσιοδοτημένης πρόσβασης, τροποποίησης και αντικατάστασης. Αυτό
+        περιλαμβάνει την ορθή κρυπτογράφησή τους και την διαγραφή όσων
+        στιγμιοτύπων δεν χρειάζονται πλέον.
 
 \clearpage
 
@@ -1585,7 +1600,7 @@ migration and rollback attacks). Από την άλλη, όσον αφορά τ
 επίπεδο λειτουργικού συστήματος. Κατά την περιγραφή της διαδικασίας δημιουργίας
 δοχείων δεν χρησιμοποιείται πλέον ο όρος εικονικοποίηση αλλά δοχειοποίηση
 (containerization). Σε αντίθεση με τις τεχνολογίες εικονικοποίησης που
-αναφέρθηκαν στο \ref{virtualizationTechnologiesIntroduction}, για την
+αναφέρθηκαν στην Ενότητα \ref{virtualizationTechnologiesIntroduction}, για την
 δοχειοποίηση δεν είναι αναγκαία η ύπαρξη υπερ-επόπτη αλλά έναν παρόμοιο ρόλο
 αναλαμβάνει η μηχανή δοχείων. Επιπλέον, ενώ οι εικονικές μηχανές καταλήγουν να
 περιέχουν εικονικό αντίγραφο του υλικού, δικό τους λειτουργικό σύστημα και
@@ -1602,7 +1617,7 @@ migration and rollback attacks). Από την άλλη, όσον αφορά τ
 τις αντίστοιχες εικόνες τους υπάρχει μια αλληλουχία βημάτων που πρέπει να
 περαιωθεί. Αρχικά, η μηχανή δοχείων θα προσπελάσει την εικόνα δοχείου
 προκειμένου να εξακριβώσει τις προδιαγραφές του. Έπειτα, με την βοήθεια των
-μεθόδων απομόνωσης που έχει στην διάθεση της μέσω των μηχανισμών
+μεθόδων απομόνωσης που έχει στην διάθεσή της μέσω των μηχανισμών
 εικονικοποίησης του πυρήνα του λειτουργικού συστήματος φιλοξενίας, θα
 δημιουργήσει ένα εικονικό περιβάλλον απομονωμένο από το ήδη υπάρχον φυσικό και
 τέλος, θα πραγματοποιήσει εκκίνηση του δοχείου ως διεργασία του συστήματος.
@@ -1626,7 +1641,7 @@ migration and rollback attacks). Από την άλλη, όσον αφορά τ
 μηχανών αλλά με κόστος την επιβάρυνση του συστήματος φιλοξενίας λόγω της
 αδυναμίας διαμοιρασμού των πόρων με τον τρόπο που το επιτυγχάνουν τα δοχεία.
 Κάθε δοχείο μοιράζεται τον πυρήνα του λειτουργικού συστήματος φιλοξενίας με τα
-υπόλοιπα και κάθε στρώση μιας εικόνας δοχείου αντιστοιχουμένη σε ένα
+υπόλοιπα ενώ κάθε στρώση μιας εικόνας δοχείου αντιστοιχουμένη σε ένα
 στιγμιότυπο λογισμικού, δύναται να χρησιμοποιηθεί ταυτοχρόνως από περισσότερα
 του ενός δοχεία προς αποφυγή διπλής αποθήκευσης
 \cite{codemotionContainerImages}. Επιπλέον, κάθε εικόνα δοχείου δύναται να
@@ -1637,7 +1652,7 @@ migration and rollback attacks). Από την άλλη, όσον αφορά τ
 
 \subsection{Μηχανές δοχείων και εικονικοποίηση σε επίπεδο ΛΣ} \label{osVirtualization}
 
-Πολλά λειτουργικά συστήματα, ειδικά αυτά που κάνουν χρήση του πυρήνα Linux
+Πολλά λειτουργικά συστήματα, ειδικά αυτά που κάνουν χρήση του πυρήνα Linux,
 διαθέτουν μηχανισμούς απομόνωσης διεργασιών και δυνατότητες εικονικοποίησης
 (λειτουργικού συστήματος), όπως είναι οι ομάδες ελέγχου (control groups) με τις
 οποίες μπορεί να επιτευχθεί ο περιορισμός πόρων σε ένα υποσύνολο διεργασιών,
@@ -1674,20 +1689,20 @@ migration and rollback attacks). Από την άλλη, όσον αφορά τ
 μεταφορά του σε ένα άλλο, εκτός εάν έχει ελεγχθεί ότι υπάρχουν όλες οι
 εξαρτήσεις που χρειάζεται στις εκδόσεις που τις χρειάζεται. Ακόμα και σε αυτήν
 την περίπτωση όμως, πέραν του κόπου για τον έλεγχο, είναι αρκετά πιθανό ένα
-δεύτερο πρόγραμμα να χρειάζεται διαφορετικές εκδόσεις των ίδιων εξαρτήσεων.
-Αυτό πρακτικά σήμαινε πως το δεύτερο αυτό πρόγραμμα θα έπρεπε να στεγαστεί σε
+άλλο πρόγραμμα να χρειάζεται διαφορετικές εκδόσεις των ίδιων εξαρτήσεων. Αυτό
+πρακτικά σήμαινε πως το έτερο αυτό πρόγραμμα θα έπρεπε να στεγαστεί σε
 διαφορετικό διακομιστή, αυξάνοντας το σχετικό κόστος.
 
 Τα προβλήματα αυτά έρχεται να λύσει η τεχνολογία της δοχειοποίησης. Με τη
 δοχειοποίηση, είναι δυνατή η συστέγαση δοχείων, δηλ. διαφορετικών προγραμμάτων
 ή συστατικών προγραμμάτων στο ίδιο μηχάνημα (είτε αυτό είναι φυσικό είτε
-εικονικό). Όπως αναφέραμε στο \ref{containerManagement}, από το 2013 και έπειτα
-η άφιξη του Docker επιτάχυνε κατά πολύ την υιοθέτηση της τεχνολογίας αυτής. Σε
-τέτοιο βαθμό που σε μια έρευνα της IBM \cite{ibmContainerSurvey} βρέθηκε πως το
-61\% όσων ξεκίνησαν να χρησιμοποιούν δοχεία, το κάνουν στο 50\% ή παραπάνω των
-εφαρμογών που δημιούργησαν τα τελευταία δύο χρόνια, ενώ 64\% αυτών, αναμένουν
-στο 50\% των υπαρχουσών εφαρμογών τους να κάνουν χρήση δοχείων στα επόμενα δύο
-χρόνια.
+εικονικό). Όπως θα αναφέρουμε και στην Ενότητα \ref{containerManagement}, από
+το 2013 και έπειτα, η άφιξη του Docker επιτάχυνε κατά πολύ την υιοθέτηση της
+τεχνολογίας αυτής. Σε τέτοιο βαθμό που σε μια έρευνα της IBM
+\cite{ibmContainerSurvey} βρέθηκε πως το 61\% όσων ξεκίνησαν να χρησιμοποιούν
+δοχεία, το κάνουν στο 50\% ή παραπάνω των εφαρμογών που δημιούργησαν τα
+τελευταία δύο χρόνια, ενώ 64\% αυτών, αναμένουν στο 50\% των υπαρχουσών
+εφαρμογών τους να κάνουν χρήση δοχείων στα επόμενα δύο χρόνια.
 
 Ένας από τους χαρακτηρισμούς των δοχείων είναι η \textquote{ελαφρότητα} τους σε
 σχέση με μια εικονική μηχανή λόγω της ικανότητας τους να μοιράζονται τον πυρήνα
@@ -1701,42 +1716,291 @@ migration and rollback attacks). Από την άλλη, όσον αφορά τ
 εικονικές μηχανές, επιτρέποντας την αντίδραση σε οποιαδήποτε διακύμανση του
 φόρτου εργασίας.
 
+\subsection{Εργαλεία διαχείρισης δοχείων και έλευση του Docker} \label{containerManagement}
+
+Στις μέρες μας, η δημοτικότητα του Docker έχει συνταυτίσει τους όρους Docker
+και Container (δοχείο) αν και είναι διαφορετικοί. Παρ' όλα αυτά, η ιδέα της
+δημιουργίας απομονωμένων περιβαλλόντων εκτέλεσης λογισμικού υπήρχε προτού βγει
+το Docker στην αγορά. Ιστορικά, οι πρώτες τεχνολογίες περί δοχείων έκαναν την
+είσοδό τους από το 1979, όταν εισήχθη το chroot \cite{chrootCommand} στην
+έβδομη έκδοση του Unix \cite{containerHistory}. Πρόκειται για μια εντολή που
+περιορίζει την πρόσβαση αρχείων που διαθέτει μια εφαρμογή, σε ένα συγκεκριμένο
+φάκελο, ο οποίος ορίζεται ως ο καινούριος αρχικός (root) (για την εφαρμογή
+αυτή). Ο κύριος σκοπός του chroot ήταν η ενίσχυση της ασφάλειας ούτως ώστε στην
+περίπτωση εκμετάλλευσης μιας εσωτερικής ευπάθειας της εφαρμογής, να παραμένουν
+ανεπηρέαστα τα μέρη του συστήματος εκτός του φακέλου στον οποίο είχε πρόσβαση.
+Εκείνη την εποχή αυτό ήταν αρκετό, αλλά οι απαιτήσεις ασφαλείας με τον καιρό
+αυξάνονταν και υπήρχε η ανάγκη διαφορετικών μεθόδων απομόνωσης μιας και από
+κατασκευής του, το chroot δεν περιόριζε έναν χρήστη ή μια διεργασία με
+διαχειριστικά δικαιώματα \cite{chrootRestrictions}. Μερικά χρόνια αργότερα, το
+2004 δημιουργήθηκαν και ενσωματώθηκαν στον πυρήνα του Linux οι ομάδες ελέγχου,
+με την βοήθεια των οποίων ήταν πλέον δυνατή η απομόνωση πόρων του συστήματος σε
+ένα υποσύνολο διεργασιών.
+
+Αυτές οι τεχνολογίες σήμαναν της έναρξη της ιδέας της δοχειοποίησης και έτσι το
+2008 ήρθε στο προσκήνιο το LXC (Linux Container Technology) \footfullcite{LXC}.
+Το πρώτο εργαλείο που χρησιμοποιούσε τεχνολογίες δοχείων για την δημιουργία και
+εκτέλεση πολλαπλών λειτουργικών συστημάτων Linux στο ίδιο μηχάνημα.
+Χρησιμοποιώντας μηχανισμούς που προσέφερε το λειτουργικό σύστημα, επέτρεπε
+πλήρη εικονικοποίηση ενός στιγμιότυπου Linux σε μορφή δοχείου και παρείχε
+αρκετές λειτουργίες, όπως η δημιουργία, η εκκίνηση και η διαγραφή LXC δοχείων.
+Παρ' όλα αυτά, επικεντρωνόταν στην δοχειοποίηση λειτουργικών συστημάτων και όχι
+εφαρμογών \cite{LXCvsDocker}, καθιστώντας δύσκολη και περίπλοκη την χρήση του
+όταν η κύρια ανάγκη ήταν η απομόνωση εφαρμογών.
+
+Ενώ λοιπόν προϋπήρχαν εργαλεία διαχείρισης δοχείων, τα οποία χρησιμοποιούνται
+ακόμα και στις μέρες μας, λόγω του συνδυασμού της δυσκολίας στην χρήση τους και
+του εξειδικευμένου σκοπού ύπαρξής τους δεν είχαν υιοθετηθεί ευρέως. Όλα τα
+παραπάνω οδήγησαν στην δημιουργία του Docker το 2013, με την έλευση του οποίου
+η τεχνολογία των δοχείων εκτοξεύτηκε. Το Docker είναι ένα σύνολο προϊόντων PaaS
+(Platform-as-a-Service) (Πλατφόρμα ως Υπηρεσία). Κάθε τέτοιο προϊόν παρέχει μια
+πλατφόρμα με μηχανισμούς για συναρμολόγηση, θέση σε λειτουργία, εκτέλεση,
+ενημέρωση και διαχείριση προγραμμάτων σε μορφή δοχείων. Σε αντίθεση με το LXC,
+το Docker αποτελεί μια μηχανή δοχείων υψηλού επιπέδου με κύριο στόχο την
+δοχειοποίηση εφαρμογών. Εκτός από τον διαχωρισμό ανάμεσα στον πηγαίο κώδικα,
+τις βιβλιοθήκες και εξαρτήσεις ενός λογισμικού από το κύριο σύστημα
+(φιλοξενίας), παρέχει και δυνατότητες επικοινωνίας με αποθετήρια εικόνων
+δοχείων, όπως είναι το Docker Hub \footfullcite{dockerhub}, το επίσημο
+αποθετήριο του Docker, το Quay \footfullcite{quay}, ένα εναλλακτικό αποθετήριο
+της Red Hat ή οποιοδήποτε άλλο αποθετήριο συμβατό με τις προδιαγραφές που έχει
+ορίσει η ανοικτή δομή διοίκησης OCI (Open Container Initiative)
+\footfullcite{oci}. Μέσω τέτοιων υπηρεσιών, οι χρήστες έχουν πρόσβαση και
+διαμοιράζονται χιλιάδες εικόνες δοχείων που τους επιτρέπουν να ολοκληρώσουν
+διάφορα μέρη μιας υπάρχουσας ή νέας εφαρμογής. Επιπλέον, όντας μια μηχανή
+δοχείων υψηλού επιπέδου όλες οι λειτουργίες που θα απαιτούσαν εξειδικευμένες
+γνώσεις προκειμένου να πραγματοποιηθούν, έχουν συμπυκνωθεί σε απλές εντολές,
+καθιστώντας έτσι εύκολη την χρήση του για προγραμματιστές κάθε επιπέδου και
+απλοποιώντας κατά πολύ την διαδικασία ανάπτυξης και παράδοσης κατανεμημένων
+εφαρμογών. Προσφέροντας μια φιλική προς τον χρήστη διεπαφή, έλεγχο εκδόσεων
+(version control) για δοχεία \cite{LXCvsDocker2} και ένα οικοσύστημα γύρω από
+όλα αυτά, είναι εμφανής ο λόγος που κατάφερε να επισκιάσει το LXC.
+
+\subsection{Χρήση δοχείων στην ανάπτυξη και παράδοση εφαρμογών} \label{containerUsage}
+
+Οι μέθοδοι ανάπτυξης και παράδοσης εφαρμογών έχουν αλλάξει δραματικά τα
+τελευταία χρόνια. Από τις παραδοσιακές μεθόδους, όπως το μοντέλο καταρράκτη
+(waterfall) \cite{waterfall} βάσει του οποίου υπήρχε ένα συγκεκριμένο
+αμετάβλητο σχέδιο ανάπτυξης που καλούνταν να ακολουθήσει μια ομάδα ανάπτυξης
+λογισμικού, έχουμε φτάσει σε μια εποχή όπου οι απαιτήσεις της αγοράς αλλάζουν
+συνεχώς, με αποτέλεσμα να υπάρχει ανάγκη για καινούριες μεθόδους που να
+ανταποκρίνονται τάχιστα στις αλλαγές αυτές. Έτσι, έχουν δημιουργηθεί
+μεθοδολογίες όπως η Agile \cite{agile} κατά την οποία η ανάπτυξη και η παράδοση
+λογισμικού πραγματοποιείται σε πολλές μικρές και ευμετάβλητες φάσεις
+προκειμένου να προσαρμόζεται στις αλλαγές που ενδέχεται να υπάρξουν στον αρχικό
+σχεδιασμό. Η μεθοδολογία αυτή συνεργάζεται με πρακτικές όπως το DevOps
+\cite{devops} όπου οι ομάδες υπεύθυνες για την ανάπτυξη και λειτουργία μιας
+εφαρμογής επικοινωνούν στενά με σκοπό να υπάρχει μια συνεχής ροή παραγωγής και
+παράδοσης λογισμικού. Αυτό επιτυγχάνεται με μια πρακτική του DevOps, το CI/CD
+(Continuous Integration/Continuous Delivery) (Συνεχής Ενοποίηση/Συνεχής
+Παράδοση) \cite{cicd}. Κατά το μοντέλο αυτό, δημιουργούνται αυτοματοποιημένες
+διαδικασίες που εκτελούνται κατά την διάρκεια της ανάπτυξης και παράδοσης μιας
+εφαρμογής προκειμένου να πραγματοποιείται έλεγχος της ποιότητας του κώδικα, να
+εντοπίζονται σφάλματα και να παράγονται εκτελέσιμα πακέτα τα οποία έπειτα
+παραδίδονται στους πελάτες. Μάλιστα, μπορεί να υποστηρίζεται και η Συνεχής
+Διάταξη (Continuous Deployment - CD) όπου τα εκτελέσιμα πακέτα των εφαρμογών
+διατάσσονται σε περιβάλλοντα παραγωγής και γίνονται άμεσα διαθέσιμα προς
+απομακρυσμένη κατανάλωση από τους πελάτες τους.
+
+Τα δοχεία αποτελούν ιδανική επιλογή για την εφαρμογή των παραπάνω μεθοδολογιών
+και πρακτικών καθώς επιτρέπουν το γρήγορο και αποτελεσματικό πακετάρισμα
+εφαρμογών και την εκτέλεσή τους σε οποιοδήποτε περιβάλλον. Λόγω των
+χαρακτηριστικών τους, εξαλείφουν τυχόν προβλήματα ασυμβατότητας μεταξύ των
+περιβαλλόντων εκτέλεσής τους και προσφέρουν μεγαλύτερη αποδοτικότητα πόρων αφού
+μπορεί κανείς να εκτελέσει πολλά περισσότερα αντίγραφα ενός προγράμματος για
+συγκεκριμένη ποσότητα πόρων σε σχέση με τον αριθμό που θα μπορούσε να εκτελέσει
+χρησιμοποιώντας εικονικές μηχανές πάνω από αυτούς τους πόρους. Γεγονός που
+μειώνει ιδιαίτερα το κόστος λειτουργίας και αυξάνει την κλιμακωσιμότητα.
+Επιπλέον, λόγω της ταχείας διάθεσης και εκτέλεσής τους, συμβαδίζουν πλήρως με
+τον ρυθμό ανάπτυξης και παράδοσης που υποστηρίζουν οι παραπάνω μεθοδολογίες.
+Έχοντας αυτά υπόψιν, γίνεται εμφανής και ο λόγος που τα δοχεία είναι η
+προτιμότερη επιλογή για την ανάπτυξη και παράδοση εφαρμογών που ακολουθούν την
+αρχιτεκτονική μικρο-υπηρεσιών. Επιπρόσθετα, η ανεξαρτησία των δοχείων μεταξύ
+τους, καθιστά πιο σταθερή την εφαρμογή αφού σε περίπτωση που κάποιο από αυτά
+αποτύχει, η υπόλοιπη εφαρμογή θα συνεχίσει να λειτουργεί κανονικά και η
+ανακατασκευή του δοχείου που απέτυχε μπορεί να επιτευχθεί εύκολα και γρήγορα με
+μια απλή τροποποίηση της εκάστοτε εικόνας δοχείου.
+
+\subsection{Χρήσεις του Docker στο νέφος} \label{dockerInCloudComputing}
+
+Οι δυνατότητες που προσφέρει το Docker το καθιστούν την καταλληλότερη επιλογή
+τόσο για επιχειρήσεις που λειτουργούν αποκλειστικά με ενοικιαζόμενους
+υπολογιστικούς πόρους όσο και για αυτές που επιλέγουν να λειτουργούν με έναν
+συνδυασμό ενοικιαζόμενων και ιδιόκτητων φυσικών εγκαταστάσεων. Υπάρχουν δύο
+βασικές περιπτώσεις χρήσης του Docker στο νέφος. Συγκεκριμένα αυτές είναι: η
+εγκατάσταση δοχείων σε εικονικές μηχανές και η εγκατάσταση δοχείων έμμεσα σε
+πόρους χωρίς την ανάγκη δημιουργίας εικονικής μηχανής. Η δεύτερη περίπτωση
+χρήσης εντάσσεται στην κατηγορία υπηρεσιών CaaS \cite{caas} (Container as a
+Service), όπως η ECS (Elastic Container Service) της Amazon. Μια υπηρεσία όπου
+ένας πάροχος νέφους αντί να παρέχει πρόσβαση σε υπολογιστικούς πόρους γενικού
+σκοπού, παρέχει μια ευέλικτη υποδομή, έτοιμη για την εκτέλεση δοχείων
+\cite{caasVsIaas}.
+
+Από τις δύο αυτές επιλογές, η πρώτη προσφέρει μια ευελιξία ως προς την
+διαμόρφωση του περιβάλλοντος εκτέλεσης των δοχείων. Οι χρήστες έχουν την
+δυνατότητα να ακολουθήσουν ορισμένες ορθές πρακτικές ασφαλείας που μπορεί να
+έχουν θεσπιστεί στην εταιρεία τους, να εγκαταστήσουν επιπλέον λογισμικό
+παρακολούθησης και ελέγχου ποιότητας των δοχείων και να προσαρμόσουν το
+περιβάλλον εκτέλεσης των δοχείων στις ανάγκες τους. Επιπλέον, η ύπαρξη μιας
+επιπλέον στρώσης απομόνωσης μεταξύ των δοχείων και του κύριου συστήματος
+αποτελεί ένα επιπρόσθετο εμπόδιο σε περιπτώσεις που ένα δοχείο βρεθεί σε
+κατάσταση παραβίασης. Το Docker επιτρέποντας μέσω των δοχείων την περιορισμένη
+έκθεση των πόρων του συστήματος στον έξω κόσμο, καθιστά ευκολότερη την
+ανίχνευση και απομόνωση των προβλημάτων ασφαλείας, καθώς επίσης και την
+αποκατάστασή τους.
+
+Από την άλλη, η δεύτερη περίπτωση χρήσης επιτρέπει στις επιχειρήσεις/πελάτες να
+επικεντρωθούν στην ανάπτυξη των δοχειοποιημένων εφαρμογών τους και να αφήσουν
+την διαχείριση της υποδομής στον πάροχο νέφους. Αυτό είναι ιδιαίτερα χρήσιμο σε
+περιπτώσεις που οι επιχειρήσεις δεν έχουν υπαλλήλους με την απαραίτητη εμπειρία
+και ικανότητες σε αυτόν τον τομέα ή δεν έχουν τον απαραίτητο προϋπολογισμό για
+αυτό. Η χρήση υπηρεσιών CaaS αυτομάτως εξασφαλίζει στις επιχειρήσεις τα
+πλεονεκτήματα των υπηρεσιών IaaS όπως η κλιμάκωση, η αντοχή σε αποτυχίες και η
+ευελιξία, ενώ ταυτόχρονα προσφέρει και τα πλεονεκτήματα των δοχείων, όπως η
+ταχεία διάθεση και απόσυρσή τους αλλά και η υψηλή τους απόδοση κατά την
+εκτέλεση. Συγκεκριμένα, μέσω των υπηρεσιών CaaS, οι χρήστες διαθέτουν
+δυνατότητες ενορχήστρωσης δοχείων \cite{howCaasWorks} χωρίς την ανάγκη
+χειροκίνητου στησίματος πλατφορμών, όπως το Kubernetes \cite{kubernetes} και το
+Docker Swarm \cite{dockerSwarm}, που παρέχουν αυτή την δυνατότητα. Επιπρόσθετα,
+οι πάροχοι υπηρεσιών CaaS έχουν την κατάλληλη τεχνογνωσία για να προστατεύσουν
+τις υπηρεσίες τους, εξασφαλίζοντας ένα υψηλό επίπεδο ασφάλειας για τις
+εφαρμογές που τις χρησιμοποιούν.
+
+Σε κάθε περίπτωση, λόγω των πλεονεκτημάτων που παρέχει η χρήση δοχείων, είναι
+πολύ συνήθης η θέση σε λειτουργία, εφαρμογών μέσω Docker σε περιβάλλοντα νέφους
+επειδή αυτό απομονώνει τις αναγκαίες βιβλιοθήκες και εξαρτήσεις τους από το
+υπόλοιπο σύστημα και επιτρέπει την αποδοτικότερη διαχείριση των εφαρμογών αυτών
+μέσω της διεπαφής του με εντολές για εκκίνηση, επιτήρηση πόρων, παύση και άλλες
+λειτουργίες. Τα προβλήματα που μπορεί να προέκυπταν σε ένα περιβάλλον
+ανάπτυξης, όπως μη συμβατές εκδόσεις προγραμμάτων και η δυσκολία διαχείρισής
+τους, εξαλείφονται με την χρήση δοχείων αφήνοντας το Docker να εγκαθιδρύσει
+έναν συστημικό τρόπο διανομής και ελέγχου εφαρμογών. Επιπροσθέτως, καθιστά πολύ
+εύκολη τη μεταφορά τους σε οποιοδήποτε μηχάνημα (εφόσον αυτό υποστηρίζει την
+εκτέλεση της μηχανής δοχείων του Docker) ή ακόμα και νέφος, θέτοντας το
+κορυφαία επιλογή για επιχειρήσεις που επιλέγουν να ακολουθήσουν την στρατηγική
+πολλαπλών νεφών (multi-cloud computing) κατά την κατασκευή εφαρμογών. Δηλαδή να
+μην βασίζονται αποκλειστικά σε έναν πάροχο νέφους για όλες τις λειτουργίες μιας
+εφαρμογής \cite{multiCloud} αλλά να εκμεταλλεύονται τα οφέλη (πχ. περισσότερη
+ασφάλεια, ποιότητα και αυξημένη διαθεσιμότητα) χρήσης υπηρεσιών από πολλούς
+παρόχους με βάση τις ανάγκες τους.
+
 \subsection{Δοχειοποίηση Εφαρμογών (Application Containerization)} \label{applicationContainerization}
 
-Τα δοχεία ενθυλακώνουν ένα λογισμικό ή μέρος εφαρμογής ως ένα αυτόνομο πακέτο
-που περιέχει τον κώδικα, τις βιβλιοθήκες και τις εξαρτήσεις που χρειάζεται για
-να εκτελεστεί. Οι διεργασίες ενός δοχείου θεωρούνται απομονωμένες με την έννοια
-ότι δεν έχουν ανάγκη για ένα αντίγραφο του λειτουργικού συστήματος αλλά αντ'
-αυτού μιας μηχανής εκτέλεσης δοχείων (container execution engine) στο μηχάνημα
-(φιλοξενίας) που λειτουργεί ως διαμεσολαβητής των δοχείων για να μοιράζονται το
-ίδιο λειτουργικό σύστημα και κατά προέκταση τους υποκείμενους πόρους του μεταξύ
-τους. Κοινές βιβλιοθήκες ή εκτελέσιμα αρχεία μιας στρώσης εικόνας δοχείων
-μπορούν επίσης να χρησιμοποιηθούν για την δημιουργία πολλών δοχείων,
-συμβάλλοντας έτσι στην εξάλειψη περιττής υπολογιστικής ισχύος, καθιστώντας τα
-δοχεία μικρά στον χώρο που καταλαμβάνουν, γρήγορα στην εκκίνηση και ικανά να
-εκτελεστούν σε οποιαδήποτε πλατφόρμα ή περιβάλλον νέφους
-\cite{ibmContainerizationDefinition}.
+Τα δοχεία ενθυλακώνουν ένα λογισμικό ή ένα συστατικό (component) εφαρμογής ως
+ένα αυτόνομο πακέτο που περιέχει τον κώδικα, τις βιβλιοθήκες και τις εξαρτήσεις
+που χρειάζεται για να εκτελεστεί. Οι διεργασίες ενός δοχείου θεωρούνται
+απομονωμένες με την έννοια ότι δεν έχουν ανάγκη για ένα αντίγραφο του
+λειτουργικού συστήματος αλλά αντ' αυτού μιας μηχανής εκτέλεσης δοχείων
+(container execution engine) στο μηχάνημα (φιλοξενίας) που λειτουργεί ως
+διαμεσολαβητής των δοχείων για να μοιράζονται το ίδιο λειτουργικό σύστημα και
+κατά προέκταση τους υποκείμενους πόρους του μεταξύ τους. Κοινές βιβλιοθήκες ή
+εκτελέσιμα αρχεία μιας στρώσης εικόνας δοχείων μπορούν επίσης να
+χρησιμοποιηθούν για την δημιουργία πολλών δοχείων, συμβάλλοντας έτσι στην
+εξάλειψη περιττής υπολογιστικής ισχύος, καθιστώντας τα δοχεία μικρά στον χώρο
+που καταλαμβάνουν, γρήγορα στην εκκίνηση και ικανά να εκτελεστούν σε
+οποιαδήποτε πλατφόρμα ή περιβάλλον νέφους \cite{ibmContainerizationDefinition}.
 
 Η δοχειοποίηση εφαρμογών αποτελεί εν γένει την πιο δημοφιλή μορφή δοχειοποίησης
 που χρησιμοποιείται σήμερα. Είθισται να χρησιμοποιείται σε περιπτώσεις χρήσης
 μικρο-υπηρεσιών, CI/CD pipelines, επαναλαμβανόμενων διεργασιών και εφαρμογής
 μεθόδων DevOps \cite{applicationContainerization}.
 
-\subsection{Πλεονεκτήματα Δοχειοποίησης} \label{containerizationAdvantages}
+\subsection{Πλεονεκτήματα δοχείων έναντι εικονικών μηχανών} \label{containerAdvantages}
+
+Ενώ μια εικονική μηχανή είναι μια πλήρης αναπαράσταση ενός φυσικού διακομιστή,
+ένα δοχείο εξομοιώνει μονάχα το περιβάλλον εκτέλεσης ενός λογισμικού. Αυτό
+σημαίνει πως εάν θεωρηθεί ως τελικός στόχος η εκτέλεση ενός λογισμικού
+απομονωμένο από το υπόλοιπο σύστημα, αυτό επιτυγχάνεται με δύο διαφορετικούς
+τρόπους, αφού οι εικονικές μηχανές και τα δοχεία χρησιμοποιούν διαφορετικού
+είδους εικονικοποίηση. Στην περίπτωση των δοχείων δεν έχουμε απομόνωση μηχανών
+αλλά διεργασιών. Γεγονός που συμβάλλει στην αποφυγή της επιβάρυνσης του
+συστήματος που θα επιβάλλονταν από τις διεργασίες του υπερ-επόπτη και της
+καθυστέρησης που θα υπήρχε για την εκκίνηση ενός ολόκληρου λειτουργικού
+συστήματος. Επιπλέον, η μη χρήση τεχνολογιών εικονικοποίησης σε επίπεδο υλικού
+αυξάνει την μεταφερσιμότητα των δοχείων αφού σε μια εικόνα δοχείου μπορούν να
+ορισθούν όλες οι απαραίτητες εξαρτήσεις ενός λογισμικού και να αναδημιουργηθούν
+σε οποιοδήποτε περιβάλλον νέφους.
+
+Παρ' όλο που πολλές φορές τα δοχεία συγχέονται με τις εικονικές μηχανές, οι δύο
+αυτές έννοιες έχουν αρκετές διαφορές στην αρχιτεκτονική τους. Στην παραδοσιακή
+εικονικοποίηση είτε αυτή γίνεται στις υπάρχουσες υποδομές μιας επιχείρησης είτε
+σε ένα περιβάλλον νέφους, ένας υπερ-επόπτης πρέπει να χρησιμοποιηθεί για να
+εικονικοποιήσει φυσικό υλικό. Κάθε εικονική μηχανή έχει ένα δικό της
+λειτουργικό σύστημα και ένα εικονικό αντίγραφο του υλικού που απαιτεί για να
+εκτελεστεί μαζί με μια εφαρμογή, τις βιβλιοθήκες και τις εξαρτήσεις της. Από
+την άλλη, ένα δοχείο αντί να εικονικοποιήσει το υλικό, εικονικοποιεί το
+λειτουργικό σύστημα ούτως ώστε κάθε δοχείο να περιέχει μόνο την εφαρμογή, τις
+βιβλιοθήκες και τις εξαρτήσεις της \cite{ibmContainerVsVm}.
+
+\noindent Το Σχήμα \ref{fig:containerVsVm} παρουσιάζει τις διαφορές ανάμεσα
+στην αρχιτεκτονική της εικονικοποίησης και των δοχείων.
+
+\begin{center}
+\begin{figure}[!ht]
+\centering
+    \includegraphics[width = .8\textwidth]{Figures/RedHat_Virtualization/virtualization-vs-containers_transparent.png}
+    \captionof{figure}{Χρήση εικονικοποίησης έναντι δοχείων \cite{redhatVirtualizationDefinition}}
+    \label{fig:containerVsVm}
+\end{figure}
+\vspace*{-30pt}
+\end{center}
+
+\clearpage
+
+Η απουσία του εικονικού λειτουργικού υλικού είναι που καθιστά τα δοχεία
+γρήγορα, φορητά και μικρότερα σε μέγεθος. Για να γίνει πιο εμφανής η διαφορά,
+σύμφωνα με τη Red Hat \cite{redhatContainerVsVm}, το μέγεθος των εικονικών
+μηχανών είναι της τάξεως των gigabyte ενώ των δοχείων είναι της τάξεως των
+megabyte. Πολλές φορές, όπως αναφέρεται και σε μια δημοσίευση
+\cite{ibmContainerVsVm} της \citeauthor{ibmContainerVsVm}, τα δοχεία
+χρησιμοποιούνται για εφαρμογές αρχιτεκτονικής μικρο-υπηρεσιών (microservices),
+όπου κάθε ξεχωριστό κομμάτι (δηλ. μικρο-υπηρεσία) αντιπροσωπεύει ένα συστατικό
+της εφαρμογής που παίρνει την μορφή ενός δοχείου. Με αυτόν τον τρόπο, είναι
+ευκολότερη η κλιμάκωση μιας εφαρμογής απ' ότι θα ήταν με μια μονολιθική
+αρχιτεκτονική. Αυτό συμβαίνει διότι μπορεί να κλιμακώνεται μόνο το μέρος ή τα
+μέρη της που έχουν αύξηση του φόρτου εργασίας τους, μέσω της χρήσης
+περισσότερων δοχείων που αντιστοιχούν σε αυτά τα μέρη/μικρο-υπηρεσίες.
+Αντιθέτως, η κλιμάκωση μιας μονολιθικής εφαρμογής θα απαιτούσε την δημιουργία
+πολλαπλών δοχείων μεγάλου μεγέθους ή πολλαπλών εικονικών μηχανών, οδηγώντας σε
+μεγάλη και αχρείαστη σπατάλη πόρων. Λόγω του γεγονότος πως μια εφαρμογή
+αποτελείται από πολλαπλές μικρο-υπηρεσίες, οι οποίες μπορεί να έχουν πολλαπλά
+στιγμιότυπα (δηλ. μεγάλο αριθμό δοχείων) ανά πάσα χρονική στιγμή, απαιτείται η
+χρήση μιας πλατφόρμας ενορχήστρωσης δοχείων για την αυτοματοποίηση της
+εγκατάστασης, εκτέλεσης και κλιμάκωσης της εφαρμογής κατά μήκος πολλαπλών πόρων
+(δηλ. εικονικών ή φυσικών μηχανών), όπως είναι το Kubernetes ή το Docker Swarm.
+Από την άλλη, αν είναι επιθυμητή η ενορχήστρωση των δοχείων μιας εφαρμογής σε
+έναν πόρο (φυσικό ή εικονικό μηχάνημα), τότε είναι δυνατή η χρήση εργαλείων
+όπως το Docker Compose.
+
+Το μόνο μειονέκτημα της τεχνολογίας των δοχείων, το οποίο δεν επηρεάζει κατά
+πολύ τη χρήση τους, είναι το γεγονός ότι δοχεία που δημιουργήθηκαν για να
+εκτελούν προγράμματα που απαιτούν την ύπαρξη του λειτουργικού συστήματος
+Windows δε μπορούν να εκτελεστούν σε ένα περιβάλλον με τον πυρήνα του Linux και
+το ίδιο ισχύει και αντιστρόφως \cite{containerOSlimitations}.
+
+Εν γένει, τα βασικότερα πλεονεκτήματα των δοχείων σε σχέση με τις εικονικές
+μηχανές είναι ο διαμοιρασμός του πυρήνα του λειτουργικού συστήματος φιλοξενίας
+και η μεταφερσιμότητά τους. Το γεγονός ότι μοιράζονται τον ίδιο πυρήνα έχει ως
+αποτέλεσμα να μην χρειάζεται να απονεμηθούν πόροι για εικονικοποίηση μηχανών με
+σκοπό την στέγαση ενός ολόκληρου ξεχωριστού λειτουργικού συστήματος (όπως
+γίνεται στις εικονικές μηχανές). Επιπλέον, τα δοχεία μπορούν να εκτελεστούν σε
+οποιοδήποτε περιβάλλον είναι ήδη εγκατεστημένη μια μηχανή δοχείων (όπως το
+Docker) όπου μάλιστα η ταχύτητα δημιουργίας τους είναι πολύ πιο γρήγορη σε
+σχέση με αυτή των εικονικών μηχανών λόγω του μικρού μεγέθους και των ελάχιστων
+μη λειτουργικών απαιτήσεών τους.
+
+\clearpage
 
 Τα δοχεία προσφέρουν μια σειρά από πλεονεκτήματα σε σχέση με τις παραδοσιακές
 εικονικές μηχανές. Αυτά, σύμφωνα με την
 \citeauthor{ibmContainerizationDefinition}
-\cite{ibmContainerizationDefinition}, είναι τα εξής:
+\cite{ibmContainerizationDefinition}, μπορούν να συνοψιστούν ως εξής:
 
 \begin{itemize}
 
-\clearpage
-
     \item \textbf{Mεταφερσιμότητα}:
 
         Τα δοχεία είναι ανεξάρτητα από το λειτουργικό σύστημα και το περιβάλλον
-        εκτέλεσης τους και ως εκ τούτου μπορούν να εκτελεστούν σε οποιαδήποτε
+        εκτέλεσής τους και ως εκ τούτου μπορούν να εκτελεστούν σε οποιαδήποτε
         πλατφόρμα ή περιβάλλον νέφους ομοιόμορφα και με συνέπεια. Εφόσον τα
         κομμάτια ενός προγράμματος μπορούν να ορισθούν σε ένα μονάχα αρχείο
         κειμένου και να κατασκευαστούν με αυτοματοποιημένο τρόπο οπουδήποτε,
@@ -1776,7 +2040,7 @@ migration and rollback attacks). Από την άλλη, όσον αφορά τ
 
 \clearpage
 
-    \item \textbf{Αποδοτικότητα}:
+    \item \textbf{Μέγιστη χρηστικότητα πόρων}:
 
         Το γεγονός ότι τα δοχεία μοιράζονται το ίδιο ΛΣ και κοινά κομμάτια μιας
         στρώσης εικόνας δοχείου μπορούν να χρησιμοποιηθούν ξανά για την
@@ -1788,32 +2052,32 @@ migration and rollback attacks). Από την άλλη, όσον αφορά τ
     \item \textbf{Ευκολία διαχείρισης}:
 
         Τα δοχεία σε ένα σύστημα είναι εύκολα διαχειρίσιμα με απλές εντολές. Η
-        διαδικασία ενημέρωσης, εκκίνησης, τερματισμού τους και εν γένει
-        διαχείρισης τους είναι γρήγορη και απλή. Ακόμα και για μια επιχείρηση
-        με πολλούς διακομιστές, όπου ο αντίστοιχος φόρτος διαχείρισης θα ήταν
-        αρκετά υψηλός, υπάρχουν πλατφόρμες ενορχήστρωσης δοχείων που πέραν της
+        διαδικασία ενημέρωσης, εκκίνησης, τερματισμού και εν γένει διαχείρισής
+        τους είναι γρήγορη και απλή. Ακόμα και για μια επιχείρηση με πολλούς
+        διακομιστές, όπου ο αντίστοιχος φόρτος διαχείρισης θα ήταν αρκετά
+        υψηλός, υπάρχουν πλατφόρμες ενορχήστρωσης δοχείων που πέραν της
         αυτοματοποίησης αυτών των λειτουργιών διαχείρισης, βοηθάνε και στην
         κλιμάκωση και διαχείριση του φόρτου εργασίας των δοχειοποιημένων
-        εφαρμογών τους.
+        εφαρμογών τους κατά μήκος πολλαπλών διακομιστών.
 
     \item \textbf{Ασφάλεια}:
 
         Η απομόνωση των εφαρμογών ως δοχεία, όταν εφαρμόζεται ακολουθώντας
         ορθές πρακτικές, εγγενώς αποτρέπει την εισβολή κακόβουλου λογισμικού
         από το να επηρεάσει τα υπόλοιπα δοχεία ή το σύστημα στο οποίο
-        εκτελούνται. Συγκεκριμένα, χρησιμοποιώντας Kernel Security Modules όπως
-        είναι το AppArmor ή το SELinux μπορούν να ορισθούν άδειες ασφαλείας με
-        σκοπό τον περιορισμό του εύρους πρόσβασης του Docker στο σύστημα, ενώ
-        με access authorization plugins \cite{accessAuthorizationPlugin},
-        περιορίζεται η πρόσβαση στον δαίμονα του Docker. Επιπροσθέτως, πολύ
-        εύκολα μπορεί να περιοριστεί και η επικοινωνία μεταξύ δοχείων, καθώς
-        και με το δίκτυο του συστήματος.
+        εκτελούνται. Συγκεκριμένα, χρησιμοποιώντας Kernel Security Modules,
+        όπως είναι το AppArmor ή το SELinux, μπορούν να ορισθούν άδειες
+        ασφαλείας με σκοπό τον περιορισμό του εύρους πρόσβασης του Docker στο
+        σύστημα, ενώ με access authorization plugins
+        \cite{accessAuthorizationPlugin}, περιορίζεται η πρόσβαση στον δαίμονα
+        του Docker. Επιπροσθέτως, πολύ εύκολα μπορεί να περιοριστεί και η
+        επικοινωνία μεταξύ δοχείων, καθώς και με το δίκτυο του συστήματος.
 
 \end{itemize}
 
 \subsection{Διαφορές σε υλοποιήσεις της δοχειοποίησης} \label{containerizationImplementationDifferences}
 
-Στην παράγραφο \ref{containerizationDefinition} αναφέραμε την έννοια της
+Στην Ενότητα \ref{containerizationDefinition} αναφέραμε την έννοια της
 δοχειοποίησης. Η ραγδαία αύξηση του ενδιαφέροντος και της χρήσης δοχείων
 οδήγησε στην ανάγκη για πρότυπα γύρω από την τεχνολογία αυτή. Έτσι, η Open
 Container Initiative (OCI), η οποία ιδρύθηκε τον Ιούνιο του 2015 από την Docker
@@ -1826,16 +2090,18 @@ Container Initiative (OCI), η οποία ιδρύθηκε τον Ιούνιο 
 σύνολο εργαλείων DevOps, τις οποίες θα μπορούν να εκτελούν με τον ίδιο τρόπο σε
 οποιεσδήποτε υποδομές της επιλογής τους.
 
-Σήμερα αν και το Docker αποτελεί μία από τις πιο γνωστές και ευρέως
-χρησιμοποιούμενες μηχανές δοχείων, υπάρχουν πολλές άλλες υλοποιήσεις.
-Εναλλακτικές μηχανών δοχείων όπως το Podman \cite{podman} και container
-runtimes όπως το LXC και το containerd, το οποίο ήταν για καιρό η προεπιλογή
-του Docker για container runtime προτού υιοθετήσει το runC, μπορεί να έχουν
-διαφορετικά χαρακτηριστικά και προεπιλογές αλλά η υιοθέτηση και η αξιοποίηση
-των προδιαγραφών της OCI καθώς αυτές εξελίσσονται θα διασφαλίσει ότι οι
-εναλλακτικές αυτές παραμένουν ανεξάρτητες από τους προμηθευτές, πιστοποιημένες
-για να τρέχουν σε πολλαπλά λειτουργικά συστήματα και χρησιμοποιήσιμες σε
-πολλαπλά περιβάλλοντα \cite{ibmContainerizationDefinition}.
+Σήμερα, αν και το Docker αποτελεί μία από τις πιο γνωστές και ευρέως
+χρησιμοποιούμενες μηχανές δοχείων, υπάρχουν πολλές άλλες εναλλακτικές
+υλοποιήσεις. Για παράδειγμα, το Podman \cite{podman} είναι μια γνωστή
+εναλλακτική μηχανή δοχείων ενώ το LXC και το containerd είναι εναλλακτικά
+container runtimes - μάλιστα το τελευταίο ήταν για καιρό η προεπιλογή του
+Docker για container runtime προτού υιοθετήσει το runC. Οι προαναφερόμενες
+εναλλακτικές υλοποιήσεις μπορεί να έχουν διαφορετικά χαρακτηριστικά και
+προεπιλογές αλλά η υιοθέτηση και η αξιοποίηση των προδιαγραφών της OCI καθώς
+αυτές εξελίσσονται θα διασφαλίσει ότι οι εναλλακτικές αυτές παραμένουν
+ανεξάρτητες από τους προμηθευτές, πιστοποιημένες για να τρέχουν σε πολλαπλά
+λειτουργικά συστήματα και χρησιμοποιήσιμες σε πολλαπλά περιβάλλοντα
+\cite{ibmContainerizationDefinition}.
 
 Παρότι οι προδιαγραφές της OCI έχουν ως στόχο να διασφαλίσουν την ομοιόμορφη
 λειτουργία της τεχνολογίας αυτής, υπάρχουν αρκετές διαφορές στην υλοποίηση της.
@@ -1853,19 +2119,19 @@ runtimes όπως το LXC και το containerd, το οποίο ήταν γι
 πλέον, το Podman δύναται να εκτελεστεί από έναν χρήστη πέραν του
 διαχειριστή/ριζικού (root).
 
-Ένα ακόμα εργαλείο που έχει παρόμοια αρχιτεκτονική με το Podman είναι το rkt το
-οποίο προσπαθούσε να κρατήσει μια προσέγγιση ασφαλούς σχεδιασμού εξ αρχής
-(Secure-by-design). Μπορούσε να ενσωματώσει χαρακτηριστικά ασφαλείας, όπως
-υποστήριξη SELinux, TPM measurement και εκτέλεση δοχείων σε απομονωμένες από το
-υλικό εικονικές μηχανές. Παρ' όλα αυτά, σύμφωνα με τον
+Ένα ακόμα εργαλείο που έχει παρόμοια αρχιτεκτονική με το Podman είναι το rkt
+\footfullcite{rkt} το οποίο προσπαθούσε να κρατήσει μια προσέγγιση ασφαλούς
+σχεδιασμού εξ αρχής (Secure-by-design). Μπορούσε να ενσωματώσει χαρακτηριστικά
+ασφαλείας, όπως υποστήριξη SELinux, TPM measurement και εκτέλεση δοχείων σε
+απομονωμένες από το υλικό εικονικές μηχανές. Παρ' όλα αυτά, σύμφωνα με τον
 \citeauthor{dockerAlternatives} \cite{dockerAlternatives}, έπαψε να έχει ενεργή
 ανάπτυξη και επομένως δεν θα συνεχίζει να ανταγωνίζεται παρόμοια εργαλεία στον
 κλάδο των δοχείων.
 
-Στην παράγραφο \ref{virtualizationImplementations} αναφέραμε την εικονικοποίηση
+Στην Ενότητα \ref{virtualizationImplementations} αναφέραμε την εικονικοποίηση
 λειτουργικού συστήματος και στην \ref{containerManagement} το LXC. Αποτελεί και
 αυτό ένα container runtime, με την διαφορά ότι αντί να επικεντρώνεται στην
-δοχειοποίηση εφαρμογών όπως κάνει το Docker χρησιμοποιώντας το runC, ο κύριος
+δοχειοποίηση εφαρμογών, όπως κάνει το Docker χρησιμοποιώντας το runC, ο κύριος
 σκοπός της δημιουργίας του ήταν η δοχειοποίηση λειτουργικών συστημάτων. Αν και
 χρησιμοποιείται ακόμα στις μέρες μας, η δημοτικότητα του έχει πέσει από τότε
 που το ενδιαφέρον τον επιχειρήσεων στράφηκε στην δοχειοποίηση εφαρμογών, με
@@ -1874,30 +2140,31 @@ runtimes όπως το LXC και το containerd, το οποίο ήταν γι
 
 Σχετικά με τα container runtimes runC και containerd, το πρώτο είναι ένα
 container runtime χαμηλού επιπέδου ενώ το δεύτερο υψηλού επιπέδου.
-Δημιουργήθηκαν και τα δύο από το Docker σε διαφορετικές χρονικές περιόδους και
-από τις αρχικές του εκδόσεις, το Docker χρησιμοποιούσε το containerd από
+Δημιουργήθηκαν και τα δύο από το Docker σε διαφορετικές χρονικές περιόδους. Από
+τις αρχικές του εκδόσεις, το Docker χρησιμοποιούσε το containerd από
 προεπιλογή. Μετέπειτα, αποφάσισε να το καταστήσει ένα αυτόνομο container
-runtime και αντικαταστάθηκε με το runC προκειμένου να μπορέσουν τα δοχεία του
+runtime και τον ρόλο του πήρε, το runC, προκειμένου να μπορέσουν τα δοχεία του
 Docker να δουλεύουν ευκολότερα σε διαφορετικές πλατφόρμες όπως το Kubernetes
 \cite{containerdRunc}. Επιπροσθέτως, η απόφαση αυτή κατέστησε το Docker πιο
 διαχειρίσιμο διότι πλέον αποτελούνταν από πολλά μικρότερα εργαλεία, όπου το
 καθένα από αυτά είχε συγκεκριμένους ρόλους. Αναλυτικότερα, το containerd πλέον
 είναι υπεύθυνο για την απόκτηση εικόνων δοχείων και την διαχείρισή τους, προτού
 τις μεταβιβάσει στο runC, το οποίο είναι το εργαλείο που θα αλληλεπιδράσει με
-τον πυρήνα του Linux προκειμένου να χρησιμοποιήσει χαρακτηριστικά όπως οι
-ομάδες ελέγχου (control groups) για να δημιουργήσει δοχεία.
+τον πυρήνα του Linux προκειμένου να χρησιμοποιήσει χαρακτηριστικά όπως, οι
+ομάδες ελέγχου (control groups), για να δημιουργήσει δοχεία.
 
 \subsection{Ασφάλεια στο Docker} \label{dockerSecurityMore}
 
 Οι εφαρμογές σε δοχεία έχουν ένα εγγενές επίπεδο ασφαλείας αφού μπορούν να
 εκτελούνται ως απομονωμένες διεργασίες και να λειτουργούν ανεξάρτητα από τα
-υπόλοιπα δοχεία. Με πλήρη απομόνωση θα μπορούσε να αποτραπεί στην περίπτωση
-μόλυνσης από κακόβουλο λογισμικό, ο κίνδυνος να επηρεαστούν άλλα δοχεία ή το
-ίδιο το σύστημα. Ωστόσο, η απομόνωση τους δεν είναι πλήρης. Ο διαμοιρασμός
-κομματιών μιας εφαρμογής σε δοχεία βοηθάει στην αποδοτικότητα του συστήματος
-αλλά ανοίγει και ένα παράθυρο ευκαιρίας για επιθέσεις. Το γεγονός επίσης πως
-μοιράζονται τον ίδιο πυρήνα σημαίνει πως μια επίθεση με στόχο αυτόν, μπορεί
-δυνητικά να επηρεάσει όλα τα δοχεία.
+υπόλοιπα δοχεία. Αν εξασφαλιζόταν πλήρης απομόνωση, θα μπορούσε να αποτραπεί,
+στην περίπτωση μόλυνσης από κακόβουλο λογισμικό, ο κίνδυνος να επηρεαστούν άλλα
+δοχεία ή το ίδιο το σύστημα. Ωστόσο, η απομόνωση τους δεν είναι πλήρης.
+Επομένως, ενώ ο διαμοιρασμός κομματιών μιας εφαρμογής σε δοχεία βοηθάει στην
+αποδοτικότητα του συστήματος, ανοίγει και ένα παράθυρο ευκαιρίας για επιθέσεις
+λόγω αυτής της τρωτότητας. Το γεγονός, επίσης, πως μοιράζονται τον ίδιο πυρήνα
+σημαίνει πως μια επίθεση με στόχο αυτόν, μπορεί δυνητικά να επηρεάσει όλα τα
+δοχεία.
 
 Σχετικά με τις εικόνες δοχείων που αναφέρθηκαν στο
 \ref{virtualizationTechnologiesIntroduction} και το
@@ -1984,8 +2251,9 @@ Docker να δουλεύουν ευκολότερα σε διαφορετικέ
         υπολογιστικών πόρων προκειμένου να αποφευχθεί μια επίθεση τύπου άρνησης
         υπηρεσίας, όπου μια διεργασία ή ένα σύνολο αυτών προσπαθεί να
         καταναλώσει όλους τους πόρους του συστήματος. Με τη βοήθεια των ομάδων
-        ελέγχου, επιτυγχάνεται ο έλεγχος του ποσοστού πόρων όπως CPU, μνήμης
-        και χωρητικότητας, που μπορεί να έχει κάθε δοχείο στη διάθεση του.
+        ελέγχου, επιτυγχάνεται ο έλεγχος του (μέγιστου) ποσοστού πόρων όπως
+        CPU, μνήμης και χωρητικότητας, που μπορεί να έχει κάθε δοχείο στη
+        διάθεση του.
 
 \end{itemize}
 
@@ -1994,9 +2262,9 @@ Docker να δουλεύουν ευκολότερα σε διαφορετικέ
 υπάρχει και η δυνατότητα υποστήριξης Kernel Security Modules, όπως τα SELinux
 \cite{selinux} και AppArmor \footfullcite{apparmor} αλλά και του Seccomp
 \cite{seccomp} (στην περίπτωση χρήσης LXC), καθώς επίσης και συμβατότητα με
-Linux capabilities, που θα μπορούσαν να εισάγουν ένα ακόμα επίπεδο ασφαλείας,
-αν χρησιμοποιηθούν σωστά, περιορίζοντας τα δικαιώματα των διεργασιών των
-δοχείων σε μονάχα όσα χρειάζονται. Το Docker παρέχει αρκετά υπάρχοντα μέσα
+Linux capabilities (ικανότητες), που θα μπορούσαν να εισάγουν ένα ακόμα επίπεδο
+ασφαλείας, αν χρησιμοποιηθούν σωστά, περιορίζοντας τα δικαιώματα των διεργασιών
+των δοχείων σε μονάχα όσα χρειάζονται. Το Docker παρέχει αρκετά υπάρχοντα μέσα
 άμυνας προκειμένου να προστατευτεί από επιθέσεις ακόμα και χωρίς επιπρόσθετες
 ρυθμίσεις. Παρ' όλα αυτά, οι αρχικές ρυθμίσεις ασφαλείας του είναι πιο
 ελαστικές απ' όσο χρειάζεται προκειμένου να συνεχίζει να λειτουργεί κανονικά
@@ -2042,8 +2310,9 @@ Linux capabilities, που θα μπορούσαν να εισάγουν ένα
         μια επίθεση άρνησης υπηρεσίας, πρέπει να γίνει χρήση των δυνατοτήτων
         που αναφέραμε στο \ref{dockerAttackVectorMitigation} με σκοπό τον
         αυστηρότερο έλεγχο διαμοιρασμού των πόρων του συστήματος. Με τον
-        καθορισμό διαθέσιμων πόρων για κάθε δοχείο εξ αρχής, δεν υπάρχει
-        κίνδυνος να προσπαθήσει κάποιο δοχείο να διεκδικήσει περισσότερους.
+        καθορισμό μέγιστων διαθέσιμων πόρων για κάθε δοχείο εξ αρχής, δεν
+        υπάρχει κίνδυνος να προσπαθήσει κάποιο δοχείο να διεκδικήσει
+        περισσότερους από αυτούς που μπορούν να του ανατεθούν.
 
     \item \textbf{Αποδράσεις Δοχείων (Container Breakouts)}:
 
@@ -2052,8 +2321,8 @@ Linux capabilities, που θα μπορούσαν να εισάγουν ένα
         αρχεία του κύριου συστήματος. Αυτό μπορεί να συμβεί με τη χρήση μιας
         συνάρτησης που απαιτεί δικαιώματα διαχειριστικού λογαριασμού μέσα από
         το δοχείο προκειμένου να κάνει κλήση μιας ικανότητας (capability) στην
-        οποία είχε πρόσβαση εξ αρχής. Σύμφωνα με το Docker η μόνη έκδοση που
-        μπορούσε να επηρεαστεί από αυτή την ευπάθεια ήταν η 0.11 και στην
+        οποία είχε πρόσβαση εξ αρχής. Σύμφωνα με το Docker, η μόνη έκδοσή του
+        που μπορούσε να επηρεαστεί από αυτή την ευπάθεια ήταν η 0.11 και στην
         επόμενη διορθώθηκε. Για την πρόληψη μελλοντικών μεθόδων διεκπεραίωσης
         τέτοιου είδους επίθεσης, συνίσταται να τίθενται τα δοχεία και οι
         αποθηκευτικοί τους χώροι σε κατάσταση μονάχα ανάγνωσης, καθώς και να
@@ -2062,7 +2331,7 @@ Linux capabilities, που θα μπορούσαν να εισάγουν ένα
     \item \textbf{Δηλητηριασμένες εικόνες δοχείων}:
 
         Οι εικόνες δοχείων μπορεί να περιέχουν κακόβουλο λογισμικό ή λογισμικό
-        για το οποίο έχουν βρεθεί πλέον ευπάθειες. Ο τωρινός τρόπος ελέγχου
+        για το οποίο έχουν βρεθεί (πλέον) ευπάθειες. Ο τωρινός τρόπος ελέγχου
         εγκυρότητάς τους βασίζεται μονάχα στην παρουσία ενός υπογεγραμμένου
         manifest αλλά δε γίνεται ποτέ αυθεντικοποίηση του αθροίσματος ελέγχου
         (checksum) της κάθε εικόνας. Αυτό αφήνει ανοιχτό το ενδεχόμενο ένας
@@ -2091,8 +2360,8 @@ Linux capabilities, που θα μπορούσαν να εισάγουν ένα
         Σε μια τέτοια επίθεση ένας κακόβουλος χρήστης προσπαθεί να μπει ανάμεσα
         στην επικοινωνία δύο οντοτήτων με σκοπό να αλλοιώσει, να υποκλέψει ή να
         παρακολουθεί πληροφορίες. Το καλύτερο αντίμετρο είναι η απομόνωση
-        δικτύου. Πρέπει να γίνει ρύθμιση των δοχείων με τέτοιο τρόπο ώστε να
-        μην έχουν πρόσβαση στη δικτυακή επικοινωνία του κύριου μηχανήματος ή
+        δικτύου. Πρέπει να γίνει ρύθμιση των δοχείων με τέτοιο τρόπο ώστε αυτά
+        να μην έχουν πρόσβαση στη δικτυακή επικοινωνία του κύριου μηχανήματος ή
         άλλων δοχείων. Αυτά επιτυγχάνονται με χρήση network namespaces, καθώς
         και με την ορθότερη ρύθμιση των API που χρησιμοποιεί το Docker για την
         επικοινωνία μέσω δικτύου.
@@ -2112,7 +2381,7 @@ Linux capabilities, που θα μπορούσαν να εισάγουν ένα
         διευθύνσεις, οι οποίες χρησιμοποιούνται από την εικονική γέφυρα δικτύου
         για να διανέμουν σωστά τα πλαίσια (frames) Ethernet αφού δεν υπάρχει
         φίλτρο για τα πακέτα ARP και επομένως κανένας μηχανισμός άμυνας. Γι'
-        αυτό τον λόγο τα δοχεία μπορούν να προσποιηθούν ότι είναι άλλα δοχεία ή
+        αυτό τον λόγο ένα δοχείο μπορεί να προσποιηθεί ότι είναι ένα άλλο ή
         ακόμα και το κύριο μηχάνημα. Στην περίπτωση παραβίασης ενός δοχείου,
         υπάρχει κίνδυνος ο επιτιθέμενος να υποκλέψει μυστικά της επιχείρησης ή
         των τελικών χρηστών της υπηρεσίας που η επιχείρηση προσφέρει. Ένας από
diff --git a/SettingsAndPackages/formatsAndDefs.tex b/SettingsAndPackages/formatsAndDefs.tex
index c21d87c..05468be 100644
--- a/SettingsAndPackages/formatsAndDefs.tex
+++ b/SettingsAndPackages/formatsAndDefs.tex
@@ -85,7 +85,7 @@
 \DefineBibliographyStrings{greek}{
   backrefpage={\textgreek{Αναφορά: σελίδα}},
   backrefpages={\textgreek{Αναφορά: σελίδες}},
-  urlseen = {\textgreek{Επίσκεψη}},
+  urlseen={\textgreek{Επίσκεψη}},
 }
 
 % https://tex.stackexchange.com/questions/29802/biblatex-and-new-line-for-doi-url-and-eprint
@@ -98,13 +98,16 @@
      \setunit{\par\nobreak}}
     {}}
 
- \renewbibmacro*{url+urldate}{%
+\renewbibmacro*{url+urldate}{%
   \usebibmacro{bbx:parunit}% Added
-  \printfield{url}
-
-  \printurldate
-% Space here is needed for the access date to be printed in a new line. Unfortunately it also adds a space in the footfullcite
- }
+  \iffieldundef{url}
+    {}
+    {\setunit*{\par\nobreak}%
+     \printfield{url}}
+  \iffieldundef{urlyear}
+    {}
+    {\setunit*{\addspace}%
+     \\\printurldate}}
 
 \DeclareFieldFormat[inproceedings]{pages}{#1} % to not have "Στο σελίδες" in inproceedings