I ran InterSystems IRIS containers via Rancher and Portainer it's all the same stuff. GUI over docker run.

can I deploy a container manually

Sure, to deploy a container manually it's enough to execute this command:

docker run -d
  --expose 52773
  --volume /InterSystems/durable/master:/data
  --env ISC_DATA_DIRECTORY=/data/sys
  --name iris-master
  docker.eduard.win/test/docker:master
  --log $ISC_PACKAGE_INSTALLDIR/mgr/messages.log

Alternatively, you can use GUI container management tools to configure a container you want to deploy. For example, here's Portainer web interface, you can define volumes, variables, etc there:

it also allows browsing registry and inspecting your running containers among other things:

GitHub does not offer CI functionality but can be integrated with CI engine.

what do I need to have on a production host initially?

First of all you need to have:

• FQDN
• GitLab server
• Docker Registry
• InterSystems IRIS container inside your Docker Registry

They could be anywhere as long as they are accessible from production host.

After that on a production host (and on every separate host you want to use), you need to have:

• Docker
• GitLab Runner
• Nginx reserve proxy container

After all these conditions are met you can create Continuous Delivery configuration in GitLab and it would build and deploy your container to production host.

In that case how Durable %SYS and Application data (USER NAMESPACE) appear on the production host for the first time? 

When InterSystems IRIS container is started in Durable %SYS mode, it checks directory for durable data, if it does not exist InterSystems IRIS creates it and copies the data from inside the container. If directory already exists and contains databases/config/etc then it's used.

By default InterSystems IRIS has all configs inside.

I believe it's enough to have [Final] keyword set in deployed mode to give a developer a hint that this class should not be extended.

Well, it's mainly for developers who can't take a hint.

If you want to enforce this behaviour, I would add a check into each method as a first line , something like

if $this.%ClassName(1)'="My.Class" quit $$$ERROR(50000,"don't extend this class")

Good idea.

You can also try to add a method-generator, I believe when you have a deployed class with method generator it will not be able to compile a subclass without method generator's source (though I'm not sure).

At first it didn't work - method generator by default works while deployed. Then I added a class check to generator.  Compilation was now failing, but other methods were actually compiled so I was able to call them. Finally I worked out this solution:

Class Package.Final [ Final ]
{

ClassMethod ANoExtend() [ CodeMode = objectgenerator, Final, ForceGenerate, Private ]
{
    quit:%class.Name="Package.Final" $$$OK
    quit $$$ERROR($$$GeneralError, "No extending")
}

ClassMethod ProtectedMethod() As %Status [ Private, ForceGenerate, GenerateAfter = ANoExtend ]
{
        // code
    quit $$$OK
}
}

This way each protected method should be recompiled but only after method-generator which always fails in subclasses. This way no code gets generated.

ReadOnly database could be made Read-Write. I assume developer has complete access to Cache and underlying OS.

meta data of class definition is included in the read only database

It is.

Yes.

Not without modifying system classes.

set c=##class(%Dictionary.ClassDefinition).%OpenId("Deployed.Class")
set c.Final=0
write c.%Save()

And after that compiling subclasses would be possible.

Deploying does not prevent user from removing Final keyword.

Deploying only prevents user from easily modifying source code.

Final keyword can be removed and the class extended.

To clarify, I want to deploy a class that the user would be unable to extend while having access to the system.