I am trying to run a Kibana docker container.
When I launch it I get this error
/usr/share/kibana/bin/../node/bin/node: --tls-min-v1.0 is not allowed
in NODE_OPTIONS
I cannot see any options being specified. I thought I cracked it when I noted that this option is only available in NODE > 12.00
I upgraded the container to use NODE 12.3.1 but the problem persists.
Has anyone come across this before, and if so how did you go about fixing it?
Related
I'm having issues now with my portainer. I run ubuntu with docker and portainer and I ran the apt-get upgrade and install command through the terminal to update some things. now when I go to the portainer all my containers are gone and when I go to deploy them again I get the:
failed to deploy a stack: Creating Container xxxxx Starting Error response from daemon: error while creating mount source path '/docker/ghost/mysql': mkdir /docker: read-only file system
At the time the only thing I could think of that maybe had created this issue was went ubuntu said there were updates to be installed so I let it install and then also ran the apt-get commands in terminal:
apt-get upgrade
apt-get install
My ubuntu storage has 80GB free (someone said may be a storage issue)
I was on the portainer slack channel trying to get help from a staff member he had me try "docker ps" which didn't work I had to try "sudo docker ps" which gave me that second error message listed above.https://docs.docker.com/engine/install/linux-postinstall/
permission denied while trying to connect to the docker daemon socket at unix:///var/run/docker.sock: Get "http://%2Fvar%2Frun%2Fdocker.sock/v1.24/containers/json": dial unix /var/run/docker.sock: connect: permissions denied
I also went and tried the docker group add from the docker docs and tried adding the $USER to the docker group. I have done that also, it lets me run the hello-world from the terminal but still doesn't let me deploy on portainer.
I still get the same deploy error from portainer:
failed to deploy a stack: Creating Container xxxxx Starting Error response from daemon: error while creating mount source path '/docker/ghost/mysql': mkdir /docker: read-only file system
This was from one of the stacks I tried to redeploy since it has the /docker/"ghost"/mysql. Also, doesnt let me redeploy any other stacks tried that too.
Really unsure what to do and how to fix it since it basically now doesn't let me use any of those containers. Any help will be really appreciated, quite on edge right now! Thanks
I was kinda expecting not to have any of these issues. Not event entirely sure how it happened, I'm assuming maybe when I was using the "apt-get" commands. I don't really know myself. I would just like this fixed so I can get my data and containers back up and going on portainer. Yes, I also know portainer and docker are different and portainer is only a utility for docker.
edit: to add to this I have also re-installed portainer and docker not a full docker refresh but the standard one where it keeps some of the files since I dont want to remove some of the directories where some containers keep there configs and data files
I have a Node/Angular app which works locally in a Docker instance. For deployment to a Google VM, we have a script which checks out the Git files, compiles them, copies the outputs into an nginx folder and restarts the nginx.
I have (what I thought was) identical setups on two different VMs. I test any changes on the "staging" VM and then if all is working correctly, I run them on the "production" VM.
Yesterday, this system broke. My staging VM pulls, compiles and runs the code without any issues or even warnings. The production VM gives errors during the compilation
The compilation line is
sudo $(npm bin)/ng build --prod --output-path=dist
and the first error I see is
ERROR in : Unexpected value 'AngularFireDatabaseModule in /home/redacted/ng-app/node_modules/#angular/fire/database/angular-fire-database.d.ts' imported by the module 'AppModule in /home/redacted/ng-app/src/app/app.module.ts'. Please add a #NgModule annotation.
So, I saw this question which said I should move import to the declarations section. I did this for AngularFireDatabaseModule and then it would not compile on my (working) staging server, giving me an error
Please add a #Pipe/#Directive/#Component annotation
Which this answer says means I need to move the declaration back to the imports!
My assumption is that my two supposedly identical VMs have something different about them, but I am having difficulty figuring out what.
Is there some kind soul who can help me figure out what the difference is?
Both VMs: Running Ubuntu 20.04.3 LTS (GNU/Linux 5.11.0-1028-gcp x86_64)
Both VMs up to date
Both VMs: node --version
v17.4.0
Both VMs: sudo node --version
v13.14.0
Both VMs: npm -v
8.3.1
Both VMs: sudo npm -v
6.14.4
What else should I be checking for?
OK, I can't be sure what exactly fixed it, but in the end, I had to go into the folder where the compilation was occurring and run
sudo npm update
which seemd to fix the problems. Could've sworn I did that a few times before, but ¯\(ツ)/¯
Leaving this for anyone who is despairing - the simple answers seem to work best
I recently started using docker (desktop version for Windows) for my node project development. I have a docker-compose file with volume configuration to share the project source files between my host machine and docker container.
When I need to install a new mode module, I can't do that on my host machine, of course, because it's Windows and docker is Linux or something, so I run docker exec -it my-service bash to "get into" the docker container and then run yarn add something from inside it. The problem is - yarn runs extremely slow and freezes almost all of the time. The docker container then becomes unresponsive, I cannot cancel the yarn command or stop the container using docker-compose stop. The only way I've found to recover is to restart the whole docker engine. So then, to finally install the new module, after docker engine restarts, I delete the node_modules folder and do the same steps again. This time it's still extremely slow, but it doesn't freeze somehow and actually installs the new module. But after some time, when I need to do that again, it freezes again and I have to delete node_modules again...
I would like to find the reasons why the yarn command is so slow and why it freezes.
I'm new to docker, so maybe my workflow is not correct.
I tried increasing RAM limit for docker engine from 2 GB to 8 GB and CPUs limit from 1 to 8, but it had absolutely no effect on the yarn command behavior.
My project was using file watching with chokidar, so I thought maybe that could cause the problem, but disabling it had no effect either.
I also thought the problem could be the file sharing mechanism between host machine (Windows) and docker container, but if it is the case, I do not know how to fix it. I suppose I then should somehow separate node_modules from the source directory and make them private to docker container, so that they are not shared with host machine.
This is quite a severe problem, as it slows the development down a lot. Please share any of your ideas about what could be wrong. I would even consider changing my development environment to Linux if the problem was caused by the file sharing mechanism between Windows and docker container.
I'm getting below error when running command ./fabricNetwork.sh up.
error
Error : manifest for hyperledger/fabric-ca:latest not found
Error : no such container : cli
errror screenshot
https://i.stack.imgur.com/DXSIz.jpg
docker files
https://github.com/NavyaGouru/Ashish_HLF
Try hyperledger/fabric-ca:1.4.8. latest tag has been deprecated instead use a specific tag. Fix your Local Image and Docker Image error too by updating Local Images to 1.4.8.
#alpha as already answered the question. I'd just like to add one point to it. You can pass the image tag to be used to launch the network using -i to the command. Its default value latest. You can see this by passing the --help flag to the command ./fabricNetwork.sh up.
The Local Version of the images can be found in the .env file in the directory. DOCKER_IMAGE_VERSION is the version that you pass using the -i flag. These two should have the same value otherwise you'll get this.
=================== WARNING ===================
Local fabric binaries and docker images are
out of sync. This may cause problems.
===============================================
ERROR! Fabric Docker image version of 1.4.8 does not match the versions supported by the test network.
This is a follow on from the question here:
gcloud deploy error: Image with tag google/docker-registry was not found which is based on the post here http://www.incrediblemolk.com/running-node-js-on-google-app-engine-managed-vms/ .
I've followed the steps in the second link and succeeded in getting gcloud and docker to run the github project https://github.com/GoogleCloudPlatform/appengine-nodejs-quickstart locally. However I am stuck on deployment.
After downloading the docker-registry container, I found that I had the 'insecure registry' issue, so I followed the steps in the top rated answer in the stack overflow question linked above. However when I tried to restart the daemon, I received a 'Tls message' as follows:
docker#boot2docker:/mnt/sda1/var/lib/boot2docker$ sudo /etc/init.d/docker restart
Need TLS certs for boot2docker,127.0.0.1,10.0.2.15,192.168.59.103
I was wondering if there is something that I need to do, or if this is a boot2docker issue? I noticed that in the boot2docker project on github, people mentioned 'workarounds' for disabling tls, which I managed to do by adding a line
DOCKER_TLS=no
to my /var/lib/boot2docker/profile file within the VM, and this did enable me to restart the docker daemon, however "gcloud preview app deploy --server preview.appengine.google.com ." requires that tls is enabled. So I feel like I'm untying one hand from behind my back and replacing it with the other in this instance!
Is there some fix required for this, or am I missing something important? If so, do I need to use boot2docker 1.3.0 as opposed to 1.3.1?
If anyone could help me in this matter that would be greatly appreciated.
Otherwise, my strategy I think would be to wait for these tools to mature a bit more, as I am after all using the preview version of gcloud, and I think TLS support in boot2docker is relatively new.
Yes, 1.3.1 is not compatible with our SDK. Plese use the latest (as of today) 1.3.2 or 1.3.0.