I'm using jhipster docker image to generate a jhipster project on an ubuntu 12.04.
My issue is that when I'd like to edit my files on host, these files are not owned by me. I've made some search, but found nothing.
The only idea I have is to chown the project.
Is there a clean way to edit these files from my IDE (or any text editor on my host)?
There is already a topic about it, but rather old and I'd like to use my IDE. Not edit files one by one.
Related
I have the following "problem". Let's say I set up a Docker container with Node on it and want to use it as a development container. I connect in Visual Studio Code via the extension "Remote - Containers" with the container and create a working folder, respectively I install some extensions e.g. Prettier.
If I now delete this container and create a new one with the same image, all extensions of the old container are automatically reinstalled and Visual Studio Code also tries to connect to the old working folder, which may not be available at all.
Does anyone know where this information is stored regarding the image so that I can delete it after I delete a container. I work on macOS
I have found the files related to my problem. They are located in the following path under macOS:
~/Library/Application Support/Code/User/globalStorage/ms-vscode-remote.remote-containers/imageConfigs
The .json files contain information about the workspaces folder and the installed extensions.
I'm a Docker newbie, using Docker on Mac. I'd like to debug it because I can't understand why it's doing what it's doing.
I figured I'll just find the Python files (in my case the file network.py in compose,) edit them to run my debugging logic, and then run docker.
The file I found and edited is at /usr/local/Cellar/docker-compose/1.24.1/libexec/lib/python3.7/site-packages/compose/network.py but even though I edited it, Docker doesn't seem affected, I'm not sure if it even uses that file. I tried entering 1 / 0 into that file and Docker still works, so I conclude it's not even using that file.
Where are Docker's actual Python files that it uses?
Trying to run locally a Web MVC application using Docker. Application compiles and runs fine when Set as StartUp Project outside of the docker-compose project but fails when docker-compose is Set as StartUp Project during the build when it comes to Target DockerGetServiceReferences: with
C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\Sdks\Microsoft.Docker.Sdk\build\Microsoft.VisualStudio.Docker.Compose.targets(195,5): error : The given path's format is not supported.
I have added the docker-compose through Visual Studio 2017 to an existing application as described here:
How to containerize the .NET Framework web apps with Windows Containers and Docker
I appreciate this might be quite vague so if there are any more details I could provide please let me know.
EDIT:
Adding docker-compose to just default MVC template in a new project works fine so the problem seems to be with the legacy solution. Also noticed I can't navigate docker-compose project General Properties, I get the URI formats are not supported popup error
EDIT:
Adding a brand new MVC project from the template to the solution without any references to other projects also generates the error. Could this indicate that the problem might be somewhere on the solution level?
EDIT:
I have created a new Solution file and started to migrate all the projects. This way I am successfully able to compose docker image. Once I am finished migrating all of the project I will do a comparison on .sln files and try to see what is different.
I created a new .NET Core Console Application with Visual Studio 2017 (RTM). Then added Docker support and got the docker file + compose files just fine. However there are few issues with them.
Docker compose files have version 2 which makes the build fail to the following error message
Microsoft.DotNet.Docker.CommandLineClientException: client version 1.22 is too old. Minimum supported API version is 1.24, please upgrade your client to a newer version.
This can be fixed by manually changing the compose file versions to 2.1. (not sure if valid fix) Then you'll get another error message
MSB4006 There is a circular dependency in the target dependency graph involving target "DockerCleanServiceReferences".
This I have no idea how to fix. I know the error message is due to some configuration that causes circular reference (e.g. post build event that does build)
So, any resources or tips how to package the .NET Core console application into docker container manually? I'm just getting to know Docker so don't assume I know anything of it yet.
Another question, that is there some place where I could get updated versions of these Visual Studio templates or are these known issues?
It turned out the problem for me was having my DockerFile, SLN file, and CSPROJ file all in the same folder. You know how when you create a solution, it asks you if you want to create a subdirectory? If you do not, and your SLN and CSPROJ files share the same folder, inevitably the Docker files will be added to this same folder, creating the circular reference. If your SLN file lives in the directory above your CSPROJ file, the DockerFile et al will be put into your parent directory with the SLN file, and all will be well. This solved it for me.
Can you please check if your Docker for Windows is targeting Linux? It's likely you were targeting Windows container, which is not supported with .NET Core yet.
On my first spin of VS2017 with docker, using the default template, I ran in to the same issue.
I referred to this article - https://blogs.msdn.microsoft.com/containerstuff/2017/03/13/visual-studio-2017-client-version-1-22-is-too-old/
This is what worked for me - As recommended, made this changes in docker-compose project's docker-compose.ci.build.yml :
The 'version' parameter on the top of the file which was set to 2, was change to 2.1
Repeated the same changes on the other files in the project including:
docker-compose.yml
docker-compose.override.yml
docker-compose.vs.debug.yml
docker-compose.vs.release.yml
Regarding your question on how to package a .NET Core console application into a Docker image manually. The https://github.com/dotnet/dotnet-docker-samples are intended to answer that very question. Check them out. If you run into issues with them or have suggestions please log an issue (https://github.com/dotnet/dotnet-docker-samples/issues).
Thanks for the post. We will be adding Nano Server container tooling "soon". Until then, you can work with Linux containers which will give a similar experience.
I have my features.xml file in src/main/resources/features folder , when I build my project through Jenkins after building my bundle goes to the nexus repository , my requirement is that after my bundle goes to nexus then features.xml should automatically be deployed on servicemix as part of build only. I should not open the servicemix console to install the feature. Please help
You may think about using a KAR (KAraf aRchive).
More information can be found here: http://karaf.apache.org/manual/latest-3.0.x/users-guide/kar.html
You can build а KAR (through Jenkins), containing your feature, then you can use a hot deployment.
Apache Karaf also provides a KAR deployer. It means that you can drop
a KAR file directly in the deploy folder.
Apache Karaf will automatically install KAR files from the deploy
folder. You can change the behaviours of the KAR deployer in the
etc/org.apache.karaf.kar.cfg:
I have also been working on this and my solution was to turn to automated scripting to accomplish this. I wrote a ssh and FTP based program which would stop an smx, delete the ${karaf.home}/data/cache/ directory, replace the new feature file with the one retrieved from the ftp operation, then restart the karaf container.
If you are open to looking into other possibilities:
You can look into Fuse Fabric which can link many smx Containers together and implement version increases and rollbacks. Currently I believe this would also need scripting to accomplish it automatically.
The third option is relatively new and comes in the form of Building docker images and deploying them via OpenShiftV3 which was just unveiled at the Redhat Summit 2015. Its worth noting its fairly new, but it does pack a very impressive feature set.