4. Compatible with many platforms
As of June 2016, KUSANAGI can be used as a virtual machine image with ten different public cloud services (IaaS: Infrastructure as a Service)
Public cloud services that can use KUSANAGI
- Amazon Web Services — Amazon Web Services
- Microsoft Azure — Microsoft
- SoftLayer — IBM
- Sakura Cloud — Sakura Internet
- ConoHa by GMO — GMO Internet
- Z.com Cloud — GMO Internet
- S-Port Cloud Services — Suzuyo Shinwart
- IDCF Cloud — IDC Frontier
- Cloudn — NTT Communications
- EX-CLOUD — TECHORUS
- GMO Cloud ALTUS — GMO Cloud
- NIFTY Cloud — NIFTY
Hybrid cloud services that can use KUSANAGI
- Runs on Docker
In addition to these, the Docker image “KUSANAGI Runs on Docker” (KUSANAGI RoD) has been made available by Docker Hub (in beta as of June 2016).
We plan to release a virtual machine image for local desktop development environments or on-premises solutions in 2016. By using KUSANAGI or KUSANAGI RoD, you can flexibly migrate from development to production without regardless of the platform.
5. Flexible configuration with standard technology
KUSANAGI is easily configurable to work with your company’s system environment: you can choose between Nginx and Apache web servers, and PHP 5.6, PHP 7.0, and HHVM 3.15. The initial configuration is Nginx and HHVM, but other combinations can be chosen freely. (See image 2)
Authorized administrator users can use commands to change the web server and PHP execution environment in real time.
For reference, the following commands will switch from the initial configuration to Apache and PHP 7.0.
The commands to switch to Apache and PHP 7.0.
[root@ip ~]# kusanagi httpd [root@ip ~]# kusanagi php7
Furthermore, as I explained in the previous articles, KUSANAGI uses industry standard technology.
Specifically, the base OS is CentOS 7, the web servers are Nginx 1.11 and Apache 2.4, the PHP execution environments are PHP 5.6, PHP 7.0 and HHVM 3.15, and the database system is MariaDB Galera Server 10.0.
This means less reliance on the vendor or platform’s system environment and helps prevent creating a black box. There is also less risk of being locked in to using one vendor.
6. Continuous upgradability
All of the middleware that KUSANAGI uses is in the repository and can be updated at any time with the yum command.
The first thing we will do after launching the KUSANAGI virtual machine image will be performing an update with a yum command. KUSANAGI was designed such that you can always use newest version, regardless of your platform.
Without relying only on security updates to important middleware like the PHP execution environment and web server, KUSANAGI’s design supports speedy installation and use of the newest standards such as HTTP/2 and Let’s Encrypt.
7. Consideration for security
As I mentioned, KUSANAGI can always be updated with the yum command. This includes OS and middleware security updates. WordPress itself can be updated separately but KUSANAGI’s strong point is that considers many other security issues as well.
For example, as a fundamental rule to prevent the core WordPress files from being tampered with, the core, theme, and plugin install directory cannot be written to from the server.
The template web server settings file also fixes potential security issues with the default LAMP environment and takes care of settings that are easily forgotten, such as: it prevents specific versions of SSL that are vulnerable from being used, and prevents external access through TCP Wrapper settings that filter access to the FTP service.
Finally, if you use KUSANAGI on a public cloud, you can make use of the public cloud’s security level. This means that there is multi-layer security from the infrastructure layer to the application layer. I think one could say that KUSANAGI makes it possible to run a more secure web system than running an on-premises environment on an in-house server.
In the next article, I will explain how to launch KUSANAGI, run WordPress, and give some pointers about using it. Stay tuned!