Web Development - Docker - KVM - Virtualbox Decision helping hand

English Virtualization
#1

Greetings to all.
I recently joined the community and i enjoy being here a lot so far.
What i am going to ask is something that it will probably get many replies but after many hours of searching the web i didn’t come to a conclusion.

I want to develop my sites locally in Tumbleweed (i installed it and i will definitely keep it because it is awesome) .
Working environment : Home behind a router, network virtualization : Bridged probably.

Software will be used :
1: Wordpress
2: Drupal (for learning purposes)
3: E commerce platforms

My thoughts:

A) Docker and Docker-compose

I tried Docker in other distros even windows 10 and i must say that it is truly fast with many advantages but i stumbled upon the permissions and security settings etc.

Question : What is the best practice in your opinion to run Docker ? Running Docker commands with sudo or adding the logged user to the Docker group ? (Simplicity vs security or it doesn’t matter at all in a development environment?) I know the socket runs as root.

B) Installing KVM - VirtualBox

I don’t know if by creating a virtual server with a LAMP stack will help me develop faster since i have to transfer files and many more. Also it requires a lot of configuration until it becomes usable.

Question : KVM or VirtualBox ?

C) Typical local LAMP installation

The idea of having a local installation would cause me headaches because of many packages that have to be installed

Question : Local LAMP or not ?

The major question i even asking my self all the time is : Will my final product work in any production environment ?

Thank you for the time you spend reading my thread and i am waiting for your thoughts .

#2

I’d go for a local LAMP server. Which I use myself. My schedule:

  1. Development environment -> local
  2. Testing environment -> on actual server
  3. Production -> on actual server

Simply select the LAMP server patterns package for install, let the installer do it’s job, next run the YaST HTTP module to set it up ( do’nt forget to open the firewall port(s) from there. Done.

#3

Well, your C) option has nothing to do with virtualization :wink:

Anyway, the choice of tools is usually set (or at least recommended) by the project you work for. In other words, if your prod target is bare metal (or bare VM for that matter), then why burden yourself with docker management? Not that I want to discourage you on docker, the technology is here to stay and grow. But you could just as easily mirror the prod server into a virtual machine.

Generally, I prefer sandboxing/containment as I do not want to clutter my work computers with servers. So, for me, C would only work in B, ie install the stack into a VM. On the other hand, given that I got so much used to docker, I would probably bring up a LAMP stack in docker because I am too lazy to create virtual machines lol!

#4

What you set up likely depends on what you want as a Project Manager (even if it’s only yourself as manager, coder, leader, etc)

Personally,
I prefer to build all machines related to Development from scratch. It’s only that way that I can exert complete control over the tiniest details to ensure that every person or deployment is a consistent, standardized configuration so that your code as it’s being developed can be moved from person or machine to machine and <know> that it works consistently always.

So, I avoid anything that is pre-built, or make a decision to base <everything> on an original instance of what is pre-built.

My virtual machines are <very> disposable.
I might use different machines to explore different development paths, and immediately discard something as soon as it leads to a dead end(Much better than trying to undo or reverse everything)
I make copies of machines at different stages of development, sort of like snapshots.
If I want to bring a new person into my team, I only have to give that person a copy of my virtual machine and immediately that person has a guaranteed authentic working copy of code in progress. Depending on how modular the software is, perhaps I don’t even need a CI system like Jenkins to merge/integrate work.

So,
The above describes some considerations for virtualizing at the code-writing level.

I also heavily utilize virtualization in Staging to provide a central standard as code progresses…
From the code-writing machines, I deploy to Staging machines.
Various Staging machines might be used for code-writers to do “final” testing of their code, others are used for testing.
All Staging machines are used with an eye towards ultimate progression to Production.
Also, during Final Staging I usually make some decisions on whether the code should be refactored in any way or re-deployed to a specialized virtual instance that is stripped of everything unnecessary and Production-level security applied… So, for instance in this final stage the solution might be migrated from a Virtualbox or similar “full virtualization” to something like a single-purpose Docker instance.

When code in Staging is deemed finally ready, it’s either migrated to Production or the virtual machine is simply promoted as a Production instance.
Yes, even the Production machines are virtualized.

But, what I do reflects my own personal preferences and supports how I prefer to manage code development.
I’m sure that any other person would likely have a radically different idea how to build code so would do things differently.

But, bottom line is that IMO use of any kind of virtualization is one of the most important tools for code building today.

TSU

PS
I almost never develop “locally” on a machine for a multitude of reasons…
Development requires sacrifices in overall machine security (It’s a major reason why you need to install all that other stuff for development that’s not already in your default install)
It’s too easy for bad code (unintentionally or not) to screw up a machine
You can’t easily undo what you install into your machine, eventually rendering your machine a mess
I support a multitude of coding languages, and most of them make changes to the machine.

#5

FYI
Found the following section in the Docker documentation, which has some suggestions and ideas related to building applications using docker.

Be forewarned…
This section looks like it’s useful for ideas but is very incomplete…

So, for example the nodejs lab is supposed to be an example porting a nodejs app from a normal install into a docker container.
As of today, it minimally does this but because the chosen example app depends on a MongoDB backend, the lab results in an error(and that is intentional).
To me, any example should result in an error-less success because it’s the ultimate confirmation of success.
Here’s hoping ;the author of that lab will one day complete his example or change the example to some other app without a missing dependency…

https://docs.docker.com/develop/

HTH,
TSU