It is worth to say that I have never attended
such eventsMomentum (and most probably will never do, no matter what company will held it in the future), because from my perspective such events should look like:
EMC thinks that Momentum looks like:
but in real life it looks like:
Issue #1 to address – Forced re-indexing and database changes are time consuming
Patrick offered a stateless Documentum –
- Point and run Content Server
- Binary upgrades
- No forced changes to database
- Eliminates downtime from reindexing
Able to bring in Bedrock server without any changes to database or repository.
Makes upgrades easier (and faster). Has the ability to just run “Bedrock” against existing database and content repository due to everything due to Documentum in a Docker Container.
- Portable Production Ready Images
- Continuous delivery of upgrades and patches to production
- Faster Rollback
Documentum Application Containers
- Developer – All in One container for Functional Investigation
- Service Images – Individual services containers for Agile Expansion and Load balancing
- Stateless Documentum – External Content, Database & Isolated Configuration for Fast Patching and Upgrades
Different Containers for Content Store could be more containers for xCP or other customizations.
Docker is Linux based (no support for Microsoft right now).
How to migrate to Docker environment.
- Add content server – Docker container – can operate alongside existing Documentum
- Deploy extra Docker containers to manage high volumes
- Migrate to Docker by turning off original non-Docker instances
How many people are looking at Docker (only 1 out of 60 in room)
Hot upgrades to D7.3+ (Bedrock – Feldspar…)
- Can run Bedrock on Docbase 7.2 and also have it work on a Docbase Bedrock.
- Run new version along side old version in Production
Actually, everything that was “written” about Docker sounds ridiculous… The main problem is: Docker complicates everything. Why? Let’s elaborate. First of all, what is a Docker image? It is just a tar archive where maintainer put service’s binaries among with dependencies and bootstrap procedures: take a look at my shell scenario which creates document image – there is nothing related to Docker except the command which uploads archive into the Docker repository, there is no rocket science: I may unpack my archive into specific directory and run my services inside chroot take a look at chroot usecases – they are pretty the same as Docker’s:
- Testing and development
- Dependency control
- Privilege separation
If chroot is so cool, what are the Docker’s advantages over chroot? I do believe that the answer for this question is obvious:
- Docker provides infrastructure for managing images – Docker Registry
- Docker saves storage space by taking advantage of read-only layers – Understand images, containers, and storage drivers
- Docker is able to limit operating system resources consumed by certain container – Runtime constraints on resources
- Docker manages networking – Understand Docker container networks
But if you have chosen to use Docker you must understand that your deployment/maintenance workflow changes dramatically, for example, imagine that you decided to install a patch/update in Dockerized environment (no matter Documentum (i.e. application) or operating system (i.e. platform) patch), what steps do you need to perform to achieve your goal? These steps are:
- update base image
- test new base image
- stop existing container
- remove existing container
- deploy new container
This procedure, obviously, is less straightforward than installing patches/updates using puppet, ansible or something else or even manually, however, this is how Docker workflow designed and supposed to work. Now ask yourself how many typical Documentum installation do you need to have to start taking advantage of using Docker? In my opinion dozen is not enough, if you have more you are either a large enterprise or a big consulting company, and it is not a EMC business to lecture you how to manage your environments.