Deployment By Aswat
HOW TO THINK THE CODE ?
If you can modify the lifecycle of a web request, be careful
Follow the good practice
Abuse of threads
Share data between requests, with calback, etc...
A file system is POSIX on Linux
File system is not a datastore
File System is the nightmare of ops
File System creates coupling (host provider/OS/language)
SPOF-free multi tenant File System doesn't exist
Use a Real Datastore (S3, Ceph, RiakCS)
Can be Replicated
Code vs Data
Code is a mathematical function
Data is when you need memory
Write something on the fs for the next request
Store the informations near your code
Sessions in a file system are a bad idea
Consider more things as Data
What is this data ?
Near the others ?
Need redundancy ?
Need speed ?
USE MANY DATASTORES
And Trust your middleware
User account created
send a confirmation mail
add this user in the statistics management
create a storage space
Generally, everything is sequential
Good practice is to use a broker
Use your event broker as an async manager
Bad practices with event
Cron + FS is neither an event queue nor a job scheduler
Schedule action table in Database, and wait for a loading page to launch the request is a very bad idea
Choose the technology because you love it, not because it's easy to install on your computer
Dev send the logs
Ops manage the logs
Bad idea with logs
Logs in file need to be removed
Manage to serve assets from somewhere else
a different domain name with the other asset
A Web App is not a script
Do not generate code files at run
But no more deployment with FTP/RSYNC
NEVER HOTFIX ON SERVER
DO NOT COMMIT AND SHIP DEPS
RUN YOUR APP WITHOUT WRITE PERM
Deployment is an atomic operation
It's like a compilation
Docker as an operating system builder
Always be at a clean state of the server/OS
Uptime of one year is not something to be proud
Statelessness is the key
Use env variables to define the configuration
Please use Google Chrome to obtain the best export results.
Public - 9/7/15, 3:06 AM