|
Thank you. How do you do local dev/debugging? Always connect to the remote docker image/instance?
|
|
|
|
|
Someone here set up some scripts to create the docker images and configure them. From what I understand I connect to the local docker instance.
|
|
|
|
|
|
You put everything that is to be included into the new image (except the base image) into a subdirecotry at the host. (Keep everything else out of that subdirectory!) In the root of that subdirectory you save the build script (the "Dockerfile") in the script language described at Docker Build Documentation[^].
Using the CLI interface to the daemon, you give a build command, naming your build script (note that other Docker users will frown if it is named something else than "Dockerfile" with no extension). This will not do the build at the host; it will copy the entire subdirectory into the Docker daemon, and the daemon will do the build.
The Dockerfile language is really primitive. Conceptually, the script loads the base image specified (e.g. a Linux base) and RUNs one or more executables (typically some installer), COPY from the directory tree you specified to the file system of the new image, one command line at a time. When all the RUN / COPY commands are performed, the current state, with the newly installed software, is saved as a new image. There is not much more to it, just minor details such as the command to run when the container is started, naming and other optional things.
Your first Dockerfile could consist of three lines
FROM some-baseimage
RUN myprogram-installer.exe
CMD myprogram.exe
"myprogram-installer.exe" would be placed in the directory tree that is copied to the Docker daemon.
"myprogram.exe" lives in the file system of this image only, making up a new layer of your image. It exists inside the Docker daemon only, even there invisible to other images, unless they are built using your image as base).
That's it. There is not much to learn, as long as you know how to run installers and start the application...
Note that since the entire build is done in a black box outside your control, there is no way for you to supply any sort of parameters through a dialog. All choices must be specified as arguments at the RUN line (possibly by naming a parameter file that you have COPYed to the image earlier in the Dockerfile, if the installer can be parametrized that way).
|
|
|
|
|
It's all so confusing. I checked here [^] and found none of them suitable for acquisition.
| Ravings en masse^ |
|---|
| "The difference between genius and stupidity is that genius has its limits." - Albert Einstein | | "If you are searching for perfection in others, then you seek disappointment. If you are seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
Nish Nishant wrote: Are you using Docker or similar technologies today?
Yes, in fact it's currently my main task
Nish Nishant wrote: What's been your experience like?
Pretty much wholly positive - though we're almost a classic use case. We're containerising our build system which is a mix of gulp and webpack builds across JavaScript and Typescript code bases (deprecating the former in favour of the latter) as well as cordova apps.The platform (.net) team at the other end of the corridor is doing something similar.
Nish Nishant wrote: What stack do you use it on?
Linux - the host machine doesn't matter too much, the containers are either apline or debian. From there we build the container to do what we want, such a "be a gulp environment" or "be a cordova build system". Not tried it on Windows, the other team seems to think it's fine. Doesn't work fully on Macs - runs inside an actual VM, but can be used for testing.
|
|
|
|
|
How's your development/debugging experience? Do you create local docker containers? Or do you connect to a remote docker image/instance? (example on AWS/Azure)
|
|
|
|
|
Images were Local at first, we're now using AWS ECR to store the images themselves. We don't have any need to persist intances at the moment.
We're also running the image pull and run in .sh scripts, if you have the choice I'd suggest python as an alternative if you just want something portable to run on a *NIX system. Developing has been fine, the biggest problem has been the stack we've adopted - Docker, AWS-ECR and AWS-SSM (which we're using as a secure param store) are all new to the team, and the kiddiewinks I work with have barely any BASH exposure, so there has been a learning curve.
Running locally has been fine from a debugging/dev perspective - the tooling is pretty much your favoured IDE around whatever you've decided to wrap this in (in our case BASH), the only stuff you won't be familiar with is the docker files (not difficult) and the docker framework you'll need to spin the thing up (in our case the Docker CLI, but stuff is available for python and dot net ). We also don't really attach a debugger anywhere, as the code is all BASH, so YMMV if you go down a different route.TBH it's not much different from scripting on a linux OS, our main problem has been testing in our Build Manager (Team City) where we've got the latency of build agents spinning up etc.
|
|
|
|
|
Thank you, Keith, appreciate the details. 
|
|
|
|
|
No worries, glad to help!
|
|
|
|
|
Haven't used it yet, but I'd very much like to.
I'm sure it has its problems, but it would sure as hell solve a lot of them too!
The company I currently work for has been talking about it, but they're still on Windows 7 so it's a no-go for them (for now).
They do have lots of services that all depend on one another though, so Docker would certainly help in automated testing and deployment.
|
|
|
|
|
|
|
Thank you. Will be good to read some critical and not so positive write-ups too I suppose. 
|
|
|
|
|
Nish Nishant wrote: Will be good to read some critical and not so positive write-ups too I suppose.
Oh, don't get me wrong. Docker running Linux on a Win10 box is great. It's just that Docker for Windows sucks.
|
|
|
|
|
I use Docker to create encapsulated, versioned development environments for my projects. That way I can have different package versions installed side by side, and can easily rollback environment changes. See my Luffer project for details.
|
|
|
|
|
Nice - thank you. Can you talk about you local dev experience? Do you cerate a docker image locally and work against that?
|
|
|
|
|
Yes, I run the docker container locally in detached mode, with the base directory of my project mapped into it, and use docker exec to send it commands. This is all automated / abstracted away by Luffer, the tool I mentioned earlier.
|
|
|
|
|
Excellent. Thank you for the info.
|
|
|
|
|
I use VMWare/VMPlayer when I need to test my development under different environments.
I believe Docker, or its original incarnation, was initially created to develop applications that would run within their own OS\VM-like process so that applications could be distributed without any concerns for the configuration of the host operating systems.
That phase of this development appeared to have petered out a number of years ago leaving everyone with the new construct that the current version of Docker is today.
Technically, I never understood the need for such implementations if an organization is primarily supporting one major operating system. Those that support multiple operating systems are doing it for one of two reasons; the organization has a definitive requirement to do so or they are simply stupid and like to have additional complexity in their environments so they can feel important.
In any event, though the explanations here as to what Docker actually is may be correct; to me nonetheless, it is just another form of virtualization even if the Docker supporters deny this...
Steve Naidamast
Sr. Software Engineer
Black Falcon Software, Inc.
blackfalconsoftware@outlook.com
|
|
|
|
|
I am still trying to educate myself as to all the differences and pros and cons between containers vs VMs, and it's not easy to read past the marketing hype.
|
|
|
|
|
My naïveté made me think that I could run an ASP.NET app on Docker on Linux. It was not fun and it did not work (for me).
|
|
|
|
|
ASP.NET Core should run okay, at least in theory. What problems did you run into if I may ask?
|
|
|
|
|
This was in 2015, ASP.NET core didn't exist. I tried to install Mono and the components that supported ASP.NET on Mono but I could not install them correctly, mostly due to my lack of experience.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
