 Shared JOBTBL.SYS with docker
#31424
14 Aug 19 12:19 PM
|
Joined: Oct 2015
Posts: 230
Stuart
OP
Member
|
|
OP
Member
Joined: Oct 2015
Posts: 230 |
We have no problem sharing a background process with multiple login/ashell sessions on one system, but is there any 'Ashell' reason that we can't share that same process across login/ashell sessions on different systems if the JOBTBL.SYS directory and file are shared/accessible by all those systems? Certainly, we are experiencing problems trying it at the moment. The following are the ashlog files from the two respective systems. Background system -----------------
[root@develop-bg ~]# cat /vm/miame/ashlog.log
14-Aug-19 12:38:13 [tsk:42461-0]<:(nil)> ----------------
14-Aug-19 12:38:13 [tsk:42461-0]<:(nil)> A-Shell 6.5.1664.4 launched on tsk:42461 by root
14-Aug-19 12:38:13 [tsk:42461-0]<:(nil)> jcbrebuild #0
14-Aug-19 12:38:13 [tsk:42461-1]<:(nil)> In: Nodes=1/1/30 [P], ip=127.0.0.1 0:0:0:0:0:0, (root) inodes: si=0,sm=0,rsv=0(0,0,0), j=30001a,q=300019, rc=0
14-Aug-19 12:46:41 [p173-0]<:(nil)> ----------------
14-Aug-19 12:46:41 [p173-0]<:(nil)> A-Shell 6.5.1664.4 launched on pts/0:173 by root
14-Aug-19 12:46:41 [p173-0]<:(nil)> jcbrebuild #0
14-Aug-19 12:46:41 [p173-0]<:(nil)> Removing phantom: TSKAAB (pts/1:54) pid=54
14-Aug-19 12:46:41 [p173-2]<:(nil)> Forced zap of job # 2
14-Aug-19 12:46:41 [p173-2]<:(nil)> In: Nodes=2/2/30 [P], ip=0.0.0.0 0:0:0:0:0:0, (root) inodes: si=0,sm=0,rsv=0(0,0,0), j=30001a,q=300019, rc=0
14-Aug-19 12:47:45 [p173-2]<QUIT:0x5fc> JCB Verify Error: Expected: job 2 (pts/0:173); was: 2 ()
14-Aug-19 12:47:50 [p173-2]<QUIT:0x5fc> Out: Nodes Remaining = 0P/0L, 943 reads, 17 writes, 6 kbd bytes[root@develop-bg ~]#
[root@develop-bg ~]#
Main system -----------
[root@develop-pyr /]# cat /vm/miame/ashlog.log
14-Aug-19 12:44:23 [p54-0]<:(nil)> ----------------
14-Aug-19 12:44:23 [p54-0]<:(nil)> A-Shell 6.5.1664.4 launched on pts/1:54 by root
14-Aug-19 12:44:24 [p54-0]<:(nil)> jcbrebuild #0
14-Aug-19 12:44:24 [p54-2]<:(nil)> In: Nodes=2/2/30 [P], ip=0.0.0.0 0:0:0:0:0:0, (root) inodes: si=0,sm=0,rsv=0(0,0,0), j=30001a,q=300019, rc=0
14-Aug-19 12:47:25 [p54-2]<SYSTAT:0x38a1> JCB Verify Error: Expected: job 2 (pts/1:54); was: 2 (pts/0:173)
14-Aug-19 12:47:30 [p54-2]<SYSTAT:0x38a1> Out: Nodes Remaining = 1P/1L, 648 reads, 19 writes, 14 kbd bytes[root@develop-pyr /]#
[root@develop-pyr /]#
Both can start up and the main (second) system correctly finds and uses the BG process running in the background (first) system. However, just running systat in each one can apparently cause the JOBTBL file to get zapped. The shared directory that the JOBTBL file is created in is a shared volume rather than a mounted (external) volume. This shouldn't have any affect and is done as the ownership and access permissions can't be changed for an external mounted volume. The shared directory has full (777) permissions and the JOBTBL and QFLOCK files are created with RW (666) permissions. In both cases the Ashell session is run in a root login host session.
|
|
|
|
Re: Shared JOBTBL.SYS with docker
[Re: Stuart]
#31427
14 Aug 19 02:49 PM
|
Joined: Jun 2001
Posts: 11,645
Jack McGregor
Member
|
|
Member
Joined: Jun 2001
Posts: 11,645 |
I think that as long as you set the QUEUE statement in the miame.ini to use the DISK: option (instead of MEM:), it seems like it should work. The MEM: option will almost certainly not work across systems.
|
|
|
|
Re: Shared JOBTBL.SYS with docker
[Re: Stuart]
#31428
14 Aug 19 02:58 PM
|
Joined: Oct 2015
Posts: 230
Stuart
OP
Member
|
|
OP
Member
Joined: Oct 2015
Posts: 230 |
Well, I think it's probably good that you think that, as fundamentalyy therefore, it should presumably work.
However, not for me. The MIAME.INI file does use the DISK format and points to the shared volume that is accessible to both systems, but still results in the error above.
I was hoping that the Ashell log messages might provide some clue, but perhaps I'll have to increase the level and subjects of the logging.
|
|
|
|
Re: Shared JOBTBL.SYS with docker
[Re: Stuart]
#31429
14 Aug 19 02:58 PM
|
Joined: Oct 2015
Posts: 230
Stuart
OP
Member
|
|
OP
Member
Joined: Oct 2015
Posts: 230 |
Well, I think it's probably good that you think that, as fundamentalyy therefore, it should presumably work.
However, not for me. The MIAME.INI file does use the DISK format and points to the shared volume that is accessible to both systems, but still results in the error above.
I was hoping that the Ashell log messages might provide some clue, but perhaps I'll have to increase the level and subjects of the logging.
|
|
|
|
Re: Shared JOBTBL.SYS with docker
[Re: Stuart]
#31430
14 Aug 19 02:59 PM
|
Joined: Oct 2015
Posts: 230
Stuart
OP
Member
|
|
OP
Member
Joined: Oct 2015
Posts: 230 |
Well, I think it's probably good that you think that, as fundamentalyy therefore, it should presumably work.
However, not for me. The MIAME.INI file does use the DISK format and points to the shared volume that is accessible to both systems, but still results in the error above.
I was hoping that the Ashell log messages might provide some clue, but perhaps I'll have to increase the level and subjects of the logging.
|
|
|
|
Re: Shared JOBTBL.SYS with docker
[Re: Stuart]
#31432
14 Aug 19 03:52 PM
|
Joined: Jun 2001
Posts: 11,645
Jack McGregor
Member
|
|
Member
Joined: Jun 2001
Posts: 11,645 |
Let me play with this here to see what's happening. It's definitely the case that some SYSTAT options (like /W and /K/Z) rely on inter-job signaling which wouldn't be possible across systems (or probably even between containers on the same system). But it's not clear why SYSTAT would cause the JOBTBL to be corrupted.
|
|
|
|
Re: Shared JOBTBL.SYS with docker
[Re: Stuart]
#31433
14 Aug 19 03:56 PM
|
Joined: Oct 2015
Posts: 230
Stuart
OP
Member
|
|
OP
Member
Joined: Oct 2015
Posts: 230 |
I have been using SYSTAT /N. Certainly if that is the problem, then it can possibly be avoided, but I believe there has been similar JOBTBL corruption through other programs as well. However, it is possible that it has just been SYSTAT which I have been using to try and confirm things are running as they should be. It would be quite ironic if that was actually the cause for them not to be! 
|
|
|
|
Re: Shared JOBTBL.SYS with docker
[Re: Stuart]
#31434
14 Aug 19 03:57 PM
|
Joined: Oct 2015
Posts: 230
Stuart
OP
Member
|
|
OP
Member
Joined: Oct 2015
Posts: 230 |
I have been using SYSTAT /N. Certainly if that is the problem, then it can possibly be avoided, but I believe there has been similar JOBTBL corruption through other programs as well. However, it is possible that it has just been SYSTAT which I have been using to try and confirm things are running as they should be. It would be quite ironic if that was actually the cause for them not to be!
|
|
|
|
Re: Shared JOBTBL.SYS with docker
[Re: Stuart]
#31443
14 Aug 19 07:05 PM
|
Joined: Jun 2001
Posts: 11,645
Jack McGregor
Member
|
|
Member
Joined: Jun 2001
Posts: 11,645 |
Ok, this took me awhile, but I've managed to set up the following test environment: Two Centos7 vmware machines, on the same LAN, call them M1 and M2. Both machines have independent /vm directories and independent copies of the /vm/miame/miame.ini file. M1 has Samba running, and shares its /vm/miame directory (where the qflock.sys is). M2 mounts M1's shared miame directory via the mount point /tmp/mountM1's miame.ini contains: QUEUE=600,DISK:/vm/miame/qflock.sys M2's miame.ini contains: QUEUE=600,DISK:/tmp/mount/qflock.sys So both machines are using the same qflock.sys file, but M2 is accessing it via Samba while M1 is accessing it directly. I also added the -v /tmp/mount:/tmp/mount switch to M2's docker run command so that it had access to the mounted directory outside the container. With that, I'm able to launch the container on both machines, and both can see both jobs in SYSTAT:
.systat/n/c
Status of A-Shell Version 6.5.1662.0 on Wednesday, August 14, 2019 11:59:44
TSKAAA TSKAAA JACKT450:02 DSK0:1,4 ^C VUE 1 968K
TSKAAB TSKAAB JACKT450:01 DSK0:1,4 RN SYSTAT 1 968K
(I'm connecting to both machines from the same ATE client JACKT450.) So that seems to provide some empirical confirmation of the theory. But it doesn't answer what the issue is in your configuration. One place to start might be to look at the ashlog.log file (assuming TRACE=INOUT) to see if that provides any clues. Another would be to get sufficient details on your configuration so that I can adjust my test environment to more closely match yours.
|
|
|
|
Re: Shared JOBTBL.SYS with docker
[Re: Stuart]
#31450
15 Aug 19 03:10 PM
|
Joined: Oct 2015
Posts: 230
Stuart
OP
Member
|
|
OP
Member
Joined: Oct 2015
Posts: 230 |
TRACE=INOUT is configured in both MIAME.INI files and result sin the above output, which doesn't help me that much, but might possibly have a clue for you.
I am able to easily repeat the error here, using Docker for Windows on a Windows 10 host system, with Linux Ashell images/containers. (See separate email for details, as this BB is rejecting my attempt to post the relevant details).
Last edited by Stuart; 15 Aug 19 03:12 PM.
|
|
|
|
Re: Shared JOBTBL.SYS with docker
[Re: Stuart]
#31451
15 Aug 19 03:23 PM
|
Joined: Oct 2015
Posts: 230
Stuart
OP
Member
|
|
OP
Member
Joined: Oct 2015
Posts: 230 |
Well it is apparently easily repeatable. I am using Docker for Windows on a Windows 10 host, with Linux image/containers. I have tried creating a docker file to make it easier for you, but am being beaten by the 'dockerfile' processing and your ash_install script, so here are the instructions to repeat the problem: create sys volume for shared JOB access create the following dockerfile
# Open base CentOS7 image
FROM centos:centos7
# Add required application packages
RUN yum -y update
RUN yum -y install sudo wget libstdc++.i686 ncurses-libs.i686 pcre.i686
# Set up User and groups
RUN useradd ashell
RUN usermod -a -G wheel ashell
RUN echo "ashell:ashell" | chpasswd
# add vm path and env to ashell login
RUN echo "PATH=$PATH:/vm/miame/bin" >> /home/ashell/.bash_profile
RUN echo "MIAME=/vm/miame" >> /home/ashell/.bash_profile
RUN echo "export PATH MIAME" >> /home/ashell/.bash_profile
# get ash6.5 to /tmp
RUN wget htt**://www.microsabio.net/dist/65dev/bin-linux-el7/ash-6.5.1651.8-el7.bin
RUN cpio -iuB ash_install < /ash-6.5.1651.8-el7.bin
and use this docker file with the following command to obtain a start image (include the dot on the end for the path)
docker build --rm -t centos7/ashell:v1 .
This will build an initial Ashell ready CentOS image. Then use the following to create a container and login with ashell/ashell:
docker run -it --name ashell centos7/ashell:v1 login
Now install Ashell by running the ash_install script: Then ensure we don't have any ownership or permission problems (in theory)
sudo chown -R ashell:ashell /vm/miame
sudo chmod -R 777 /vm/miame
change miame.ini for QFLOCK to DISK
sed -i 's/^QUEUE/;QUEUE/' /vm/miame/miame.ini
echo "QUEUE=100,DISK:/vm/miame/sys/qflock.sys" >> /vm/miame/miame.ini
exit and save base ashell image using the following:
docker commit ashell centos7/ashell:v2
Then open ash1 and ash2 in two separate command/shell windows on the host system, based on ashell image. :
docker run -it --name ash1 -v sys:/vm/miame/sys centos7/ashell:v2 login
docker run -it --name ash2 -v sys:/vm/miame/sys centos7/ashell:v2 login
At this point you should be able to enter Ashell on each system separately without any problems, but as soon as you run an Ashell command in one system (ISMBLD and SYSTAT used), while the other Ashell session is open, it corrupts the Job table file.
Last edited by Jack McGregor; 15 Aug 19 05:28 PM. Reason: Add note about htt** and correct typo in the docker run commands
|
|
|
|
Re: Shared JOBTBL.SYS with docker
[Re: Stuart]
#31454
15 Aug 19 05:45 PM
|
Joined: Jun 2001
Posts: 11,645
Jack McGregor
Member
|
|
Member
Joined: Jun 2001
Posts: 11,645 |
This has become quite an adventure! I'm going to try to reproduce this using Docker on a CentOS7 host, although if that doesn't succeed, I'll try the Windows 10 approach. The first issue I ran into was the volume creation command. Under docker 1.12.1 I had to use the following:
$ docker volume create --name sys
Later when I brought up the first container, I had to do a chmod on it because it was set to root:root rw-rw-rw- ...
$ sudo chmod 777 /vm/miame/sys
The only other additional step I added was to export TERM=am75g from within the container before launching ashell (only needed because I was doing this from ATE using that emulation). With that, the first container comes up as advertised. I typed in the license (thinking maybe running in demo mode was part of the issue). So far so good. But when I launched the second container, it also asked for the license, making it clear that each container was using it's own instance or view of /vm/miame/miame.ini. I let that one proceed in demo mode. SYSTAT in both containers showed only one job. And with about 15 seconds they both got the job/queue zapped problem. So we're on the same path. Where we're heading is yet to be determined, but I think it will be helpful to move the miame.ini and log file to permanent shared location. I have to think about the best way to do that but will report back soon.
|
|
|
|
Re: Shared JOBTBL.SYS with docker
[Re: Stuart]
#31459
15 Aug 19 07:07 PM
|
Joined: Jun 2001
Posts: 11,645
Jack McGregor
Member
|
|
Member
Joined: Jun 2001
Posts: 11,645 |
Ok, so here's what I did next... I left the images the way they were, but upon launching the first container, I copied /vm/miame/miame.ini to /vm/miame/sys/miame.ini (so that it would be shared), and then modified it so that the CONAME entry also pointed to that same /vm/miame/sys location (since it is associated with the license). Then I redefined the MIAME environment variable to point to /vm/miame/sys, launched ashell with the -silo switch, and entered the license. In the second container, I just needed to redefine the MIAME variable to point to /vm/miame/sys and then was able to launch it and run it alongside the first one. So to recap...
$ docker run -it --name ash2 -v sys:/vm/miame/sys centos7/ashell:v2 login
<login>
$ export TERM=am75g
$ export MIAME=/vm/miame/sys
$ ashell -silo
Inside the A-Shell session...
.SYSTAT/N/C
Status of A-Shell Version 6.5.1651.8 on Thursday, August 15, 2019 18:55:02
TSKAAA TSKAAA JACKT450:01 DSK0:1,4 ^C ABOUT 36 991K
TSKAAB TSKAAB JACKT450:03 DSK0:1,4 RN SYSTAT 26 933K
2 jobs allocated on system, 2 in use
In examining the ashlog (now shared by both containers in /vm/miame/sys) I was able to see that without the -silo switch, the second instance, being unable to communicate with the first, thinks it is a phantom and tries to take over it's job allocation. The -silo switch prevents that. You would be certainly justified in wondering where that switch came from, since it's not mentioned in the documentation! It was added quite awhile ago as an experimental workaround for some of these docker-specific issues, but apparently we never got around to documenting it, perhaps because we never really got too deep into the docker world and it didn't become (until now) an issue. Hopefully that, along with the adjustments to put the miame.ini and coname.dat into the shared volume should be sufficient to at least get multiple jobs running in a shared environment. But I'd be interested in hearing about your further exploits and objectives, so that we can address any additional necessary refinements to A-Shell and eventually document it all properly.
|
|
|
|
Re: Shared JOBTBL.SYS with docker
[Re: Stuart]
#31462
15 Aug 19 10:05 PM
|
Joined: Oct 2015
Posts: 230
Stuart
OP
Member
|
|
OP
Member
Joined: Oct 2015
Posts: 230 |
Apologies for missing the CHMOD 777 step on the shared 'sys' directory. I had used that but forgot to add it into the process actions.
Now you have mentioned the -silo option, I remember seeing it elsewhere with regard to using a split /vm/miame and /vm/sys directory structure. As I haven't implemented that yet, I had mentally disregarded it. Also, I haven't been using shared miame.ini or coname.dat files.
I'll explore with/without these above extra shared options, along with the -silo switch and let you know how it goes.
Thank you for your efforts so far. Hopefully that will be all that is required.
|
|
|
|
Re: Shared JOBTBL.SYS with docker
[Re: Stuart]
#31463
15 Aug 19 10:09 PM
|
Joined: Oct 2015
Posts: 230
Stuart
OP
Member
|
|
OP
Member
Joined: Oct 2015
Posts: 230 |
On a related point, is it correct for the 6.5 install file to leave a lot of potentially spurious files in the base (/vm/miame) directory?
|
|
|
|
Re: Shared JOBTBL.SYS with docker
[Re: Stuart]
#31464
15 Aug 19 10:37 PM
|
Joined: Jun 2001
Posts: 11,645
Jack McGregor
Member
|
|
Member
Joined: Jun 2001
Posts: 11,645 |
The -silo switch was in the ashell launch command embedded in the image we posted, but there was no mention or clarification of it anywhere so not surprising it stayed under the radar. But note that it's meaning (for which the switch name is hopefully somewhat of a mnemonic) is that these docker sessions have to operate as if in individual silos, i.e. that can't send signals to each other. A-Shell doesn't do a lot of inter-process signalling, but there is some, most notably on startup to detect whether the other jobs using up jobtbl resources exist. It really doesn't have anything to so with splitting the directory space into private and shared areas (other than that perhaps both would be motivated by the desire to run multiple sessions in some kind of coordination with each other). As for sharing the miame.ini and coname.dat, there wouldn't be any need if the license was pre-installed in the miame.ini. (For in-house use you can use your in-house license, but I'm not quite sure what the best way would be to handle distribution of images. You can't really distribute the same license, but you wouldn't want to have to enter for each session either, so you probably would want to do something like what I did.) In any case though, I recommend you move the log file to a shared directory, so that you can examine it from an outside context and see all of the logged events for all of the sessions. The default location of the ashlog file is the $MIAME location (i.e. where the miame.ini is), but you can use the LOGDIR parameter in the miame.ini to point it elsewhere. For example: On the question of the spurious files left behind, no, those really should be cleaned up. It's on my to-do list! (And if you're reading this in real-time, going to sleep should be high on your to-do list!)
|
|
|
|
Re: Shared JOBTBL.SYS with docker
[Re: Stuart]
#31465
16 Aug 19 08:14 AM
|
Joined: Oct 2015
Posts: 230
Stuart
OP
Member
|
|
OP
Member
Joined: Oct 2015
Posts: 230 |
I can confirm that the -SILO switch (and only that switch) was the culprit. It now appears to operate successfully without any other changes.
Stupidly and annoyingly, I was actually using it in most cases where Ashell was started up/used, except for one key one. Obviously it is necessary for all sessions to be using the switch, otherwise the Ashell check on start up causes the problems above.
So, apologies for possibly wasting your time investigating this. On a positive point, at least I now know that -SILO is an important element to be included and documented.
I already planned to make use of the -MNTSYS switch in the process and now, with the new knowledge and suggestions regarding the LOGDIR option for MIAME.INI and the points raised regarding MIAME.INI and CONAME.DAT, I will explore probable improvements by incorporating these extra elements in the way the images/containers are built and used.
Maybe you got something out of this as well.:)
(As to the time, it wasn't that late for me, just normal. But I did retire shortly after posting the reply).
Last edited by Stuart; 16 Aug 19 08:16 AM.
|
|
|
|
Re: Shared JOBTBL.SYS with docker
[Re: Stuart]
#31466
16 Aug 19 03:26 PM
|
Joined: Nov 2006
Posts: 2,192
Stephen Funkhouser
Member
|
|
Member
Joined: Nov 2006
Posts: 2,192 |
Hi Stuart,
Just curious as to the reason for building your own docker image; instead of, using the Microsabio image? You can use it as a base image, and create your own custom images that inherit from what Jack has done.
One of the primary benefits of docker is that the bits in the image are the same everywhere you deploy it. If you use Microsabio's base image, then the versions of all the correlated packages are for sure the same once's Jack is using, and presumably test code against.
Stephen Funkhouser
Diversified Data Solutions
|
|
|
|
Re: Shared JOBTBL.SYS with docker
[Re: Stuart]
#31467
16 Aug 19 03:44 PM
|
Joined: Jun 2001
Posts: 11,645
Jack McGregor
Member
|
|
Member
Joined: Jun 2001
Posts: 11,645 |
No apologies needed - if anything it's our fault for not documenting the -silo switch (soon to be rectified). And it was a good exercise which may lead to an improved version of the standard container.
But does lead to Stephen's questions about whether there is any reason why you can't use the standard container as the base for yours. And/or whether it would make more sense for us to adjust the standard container configuration to be more easily adaptable to typical usage scenarios.
|
|
|
|
Re: Shared JOBTBL.SYS with docker
[Re: Stuart]
#31468
16 Aug 19 04:14 PM
|
Joined: Oct 2015
Posts: 230
Stuart
OP
Member
|
|
OP
Member
Joined: Oct 2015
Posts: 230 |
Why are we not using the 'standard container'?
A number of reasons, some of which may be based on lack of knowledge or information:
1) I don't have the configuration information for the standard image and therefore, don't know what is required outside of it.
2) Because of this, I couldn't start a container based on the standard image in order to investigate it.
3) Given the problems, it was easier to start form scratch and build up. In addition, I wanted to know exactly what I was dealing with.
4) It is based on Ashell 6.5. Although this is/was OK to test the above problem, we are using 6.4 and I don't know if that is still available or not. At least I don't have a 'name/tag' for a 6.4 image.
5) Because of (1) above, I didn't know how to integrate our own requirements into the build process for the image/containers.
Going forward, it is possible/probable that we can use the standard image (at least if/when we move to 6.5), but I will need to know and understand all the variable aspects.
|
|
|
|
Re: Shared JOBTBL.SYS with docker
[Re: Stuart]
#31469
16 Aug 19 04:18 PM
|
Joined: Nov 2006
Posts: 2,192
Stephen Funkhouser
Member
|
|
Member
Joined: Nov 2006
Posts: 2,192 |
Jack, could you create a bitbucket repo with access to the Dockerfile?
Last edited by Stephen Funkhouser; 16 Aug 19 04:20 PM.
Stephen Funkhouser
Diversified Data Solutions
|
|
|
|
Re: Shared JOBTBL.SYS with docker
[Re: Stuart]
#31470
16 Aug 19 04:22 PM
|
Joined: Oct 2015
Posts: 230
Stuart
OP
Member
|
|
OP
Member
Joined: Oct 2015
Posts: 230 |
Actually, from memory I think an image is actually a compressed file of some type, so there is a way of looking inside it, but not necessarily the easiest of methods.
|
|
|
|
Re: Shared JOBTBL.SYS with docker
[Re: Stuart]
#31471
16 Aug 19 04:29 PM
|
Joined: Nov 2006
Posts: 2,192
Stephen Funkhouser
Member
|
|
Member
Joined: Nov 2006
Posts: 2,192 |
The standard is to have access to the Dockerfile, and then you can see. I use Portainer quite often to see the layers of images in a browser. You can run a portainer container on the same docker host, and then inspect the layers with it, it's pretty helpful.
Stephen Funkhouser
Diversified Data Solutions
|
|
|
|
Re: Shared JOBTBL.SYS with docker
[Re: Stuart]
#31473
16 Aug 19 05:33 PM
|
Joined: Jun 2001
Posts: 11,645
Jack McGregor
Member
|
|
Member
Joined: Jun 2001
Posts: 11,645 |
Ok, I set up a Docker repository under the MicroSabio Bitbucket and uploaded the existing Dockerfile. It could definitely use some updating (for example the WriteExcel stuff is probably obsolete now) but at least it's visible for all to see.
|
|
|
|
Re: Shared JOBTBL.SYS with docker
[Re: Stuart]
#31474
16 Aug 19 06:24 PM
|
Joined: Oct 2015
Posts: 230
Stuart
OP
Member
|
|
OP
Member
Joined: Oct 2015
Posts: 230 |
Outside of the above, for anyone that may be interested there is a way of investigating the contents and history of an image. The following comes from this Wordpress post: htt**://sreeninet.wordpress.com/2016/06/11/looking-inside-container-images/ (replace ** with ps) To see Container content in Docker format, do the following:
docker save nginx > nginx.tar
tar -xvf nginx.tar
Following files are present: manifest.json – Describes filesystem layers and name of json file that has the Container properties. <id>.json – Container properties <layer directory> – Each “layerid†directory contains json file describing layer property and filesystem associated with that layer. Docker stores Container images as layers to optimize storage space by reusing layers across images. Following are some important Container properties that we can see in the JSON file: Digest associated with each layer OS and Architecture detail Config section describes Environment like Path, working directory, command to be run, ports to be exposed, volumes to be mounted. history section describes history of each layer.
|
|
|
|
Re: Shared JOBTBL.SYS with docker
[Re: Stuart]
#31475
16 Aug 19 06:46 PM
|
Joined: Oct 2015
Posts: 230
Stuart
OP
Member
|
|
OP
Member
Joined: Oct 2015
Posts: 230 |
I think it would be useful to have details of the 'entrypoint' along with the dockerfile itself, either in the Bitbucket repository or separately on the MicroSabio website.
Last edited by Stuart; 16 Aug 19 06:47 PM.
|
|
|
|
Re: Shared JOBTBL.SYS with docker
[Re: Stuart]
#31476
16 Aug 19 07:02 PM
|
Joined: Jun 2001
Posts: 11,645
Jack McGregor
Member
|
|
Member
Joined: Jun 2001
Posts: 11,645 |
Good point - the run.sh and launchdocker scripts now posted.
|
|
|
|
Re: Shared JOBTBL.SYS with docker
[Re: Stuart]
#31477
16 Aug 19 07:18 PM
|
Joined: Oct 2015
Posts: 230
Stuart
OP
Member
|
|
OP
Member
Joined: Oct 2015
Posts: 230 |
Great, with the above information I will take a look at the standard image next week and see if/how I can use it and modify our current processes.
If nothing else, I can see if I can match the 6.5 image build using 6.4, which may make it easier to migrate later on.
|
|
|
|
|
