I am trying to implement the BYFN Hyperledger example form my Windows 10 Linux Subsystem (Ubuntu Xenial). However, the ./byfn.sh -m up command fails with the following output:
$GOPATH/fabric-samples/first-network$ ./byfn.sh -m up
Starting with channel 'mychannel' and CLI timeout of '10' seconds and CLI delay of '3' seconds
Continue? [Y/n] y
proceeding ...
2018-04-24 22:12:44.343 UTC [main] main -> INFO 001 Exiting.....
LOCAL_VERSION=1.1.0
DOCKER_IMAGE_VERSION=1.1.0
Creating peer0.org1.example.com ... done
Creating orderer.example.com ... done
Creating peer1.org1.example.com ... done
Creating peer0.org2.example.com ... done
Creating peer1.org2.example.com ... done
Creating cli ... done
OCI runtime exec failed: exec failed: container_linux.go:348: starting container process caused "exec: \"scripts/script.sh\": stat scripts/script.sh: no such file or directory": unknown
ERROR !!!! Test failed
I see that only one container is built:
$GOPATH/fabric-samples/first-network$ dps
CONTAINER ID NAMES NETWORKS STATUS SIZE
3e66d31c6b9a cli net_byfn Up 27 minutes 17B (virtual 1.46GB)
From the output it seems that the cli container cannot see the script.sh script. Thinking this maybe a docker-compose volume-bind issue I tried to check the binds in the cli container:
$GOPATH/fabric-samples/first-network$ docker exec -ti cli bash
root#3e66d31c6b9a:/opt/gopath/src/github.com/hyperledger/fabric/peer# ls scripts/
root#3e66d31c6b9a:/opt/gopath/src/github.com/hyperledger/fabric/peer# exit
exit
$GOPATH/fabric-samples/first-network$ ls scripts/
capabilities.json script.sh step1org3.sh step2org3.sh step3org3.sh testorg3.sh upgrade_to_v11.sh utils.sh
Looking at the the docker-compose-cli.yaml file I see the following binds for the cli container:
volumes:
- /var/run/:/host/var/run/
- ./../chaincode/:/opt/gopath/src/github.com/chaincode
- ./crypto-config:/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/
- ./scripts:/opt/gopath/src/github.com/hyperledger/fabric/peer/scripts/
- ./channel-artifacts:/opt/gopath/src/github.com/hyperledger/fabric/peer/channel-artifacts
My Docker settings:
$GOPATH/fabric-samples/first-network$ docker version
Client:
Version: 18.03.0-ce
API version: 1.37
Go version: go1.9.2
Git commit: 0520e24
Built: Wed Mar 21 23:05:52 2018
OS/Arch: linux/amd64
Experimental: false
Orchestrator: swarm
Server:
Engine:
Version: 18.03.0-ce
API version: 1.37 (minimum version 1.12)
Go version: go1.9.4
Git commit: 0520e24
Built: Wed Mar 21 23:14:32 2018
OS/Arch: linux/amd64
Experimental: false
$GOPATH/fabric-samples/first-network$ docker-compose version
docker-compose version 1.21.0, build 5920eb0
docker-py version: 3.2.1
CPython version: 3.6.5
OpenSSL version: OpenSSL 1.0.1t 3 May 2016
My Go version:
$GOPATH/fabric-samples/first-network$ go version
go version go1.10.1 linux/amd64
Wondering if I'm missing something. I should mention that I used the following command to start form scratch, based on a fresh set of images (no prior images) as outlined in this script:
curl -sSL https://raw.githubusercontent.com/hyperledger/fabric/master/scripts/bootstrap.sh | bash -s 1.1.0
Thanks
Its most probably the version of golang---Fabric needs go version 1.9.x and the error message exec failed: container_linux.go:348: indicates the same thing.
In my case, it was the first Note on this page https://hyperledger-fabric.readthedocs.io/en/latest/install.html
I'm running on Windows 10, but Docker won't work since i need Windows 10 Pro or better to run it. So i'm using Docker Toolbox, and must follow the Windows 7 trick of cloning the sources anywhere under C:\Users
Related
My goal is to run a docker-compose cluster on a VM from Google Cloud Platform. I have successfully installed docker and docker-compose:
$ uname -a
Linux instance-6 4.15.0-1083-gcp #94~16.04.1-Ubuntu SMP Sat Sep 5 22:53:03 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
$ docker -v
Docker version 19.03.13, build 4484c46d9d
$ docker-compose -v
docker-compose version 1.27.3, build 4092ae5d
I am following the basic tutorial to create a docker-compose cluster using: https://docs.docker.com/compose/gettingstarted/ (Steps #1-#4).
My app.py file is:
import time
import redis
from flask import Flask
app = Flask(__name__)
cache = redis.Redis(host='redis', port=6379)
def get_hit_count():
retries = 5
while True:
try:
return cache.incr('hits')
except redis.exceptions.ConnectionError as exc:
if retries == 0:
raise exc
retries -= 1
time.sleep(0.5)
#app.route('/')
def hello():
count = get_hit_count()
return 'Hello World! I have been seen {} times.\n'.format(count)
My requirements.txt file is:
flask
redis
My Dockerfile is:
FROM python:3.7-alpine
WORKDIR /code
ENV FLASK_APP app.py
ENV FLASK_RUN_HOST 0.0.0.0
RUN apk add --no-cache gcc musl-dev linux-headers
COPY requirements.txt requirements.txt
RUN pip install -r requirements.txt
EXPOSE 5000
COPY . .
CMD ["flask", "run"]
And, my docker-compose.yml is:
version: '3'
services:
web:
build: .
ports:
- "5000:5000"
redis:
image: "redis:alpine"
Running docker-compose up gives me the correct output. One of the outputs points to where the web_1 is running.
$ docker-compose up
...
web_1 | * Running on http://0.0.0.0:5000/ (Press CTRL+C to quit)
...
After pressing the link http://0.0.0.0:5000/, GCP doesn't connect. It tries to go to the URL: https://ssh.cloud.google.com/devshell/proxy?authuser=2&devshellProxyPath=%2F&port=5000&environment_name&environment_id, but then it gives the error: 500. That’s an error. There was an error. Please try again later. That’s all we know.
Going to the external IP address and putting in port 5000 also doesn't return anything. (http://IPAddress:500)
I checked the ports:
$ sudo docker-compose ps
Name Command State Ports
composetest_redis_1 docker-entrypoint.sh redis ... Up 6379/tcp
composetest_web_1 flask run Up 0.0.0.0:5000->5000/tcp
I'm not sure what the reason it. I'm guessing it is the firewall configuration from GCP. Everything is just the default settings. I also allowed HTTP and HTTPS requests in the Compute Engine VM Instance settings. Would really appreciate more guidance on what to do. Thanks in advance!
See below for full output:
$ sudo docker-compose up
Starting composetest_redis_1 ... done
Starting composetest_web_1 ... done
Attaching to composetest_redis_1, composetest_web_1
redis_1 | 1:C 23 Sep 2020 21:40:27.816 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
redis_1 | 1:C 23 Sep 2020 21:40:27.816 # Redis version=6.0.8, bits=64, commit=00000000, modified=0, pid=1, just started
redis_1 | 1:C 23 Sep 2020 21:40:27.816 # Warning: no config file specified, using the default config. In order to specify a config file use redis-server /path/to/redis.conf
redis_1 | 1:M 23 Sep 2020 21:40:27.818 * Running mode=standalone, port=6379.
redis_1 | 1:M 23 Sep 2020 21:40:27.818 # WARNING: The TCP backlog setting of 511 cannot be enforced because /proc/sys/net/core/somaxconn is set to the lower value of 128.
redis_1 | 1:M 23 Sep 2020 21:40:27.818 # Server initialized
redis_1 | 1:M 23 Sep 2020 21:40:27.818 # WARNING overcommit_memory is set to 0! Background save may fail under low memory condition. To fix this issue add 'vm.overcommit_memory = 1' to /etc/sysctl.conf and then reboot or run the command 'sysctl vm.overcommit_memory=1' for this to take effect.
redis_1 | 1:M 23 Sep 2020 21:40:27.819 * Loading RDB produced by version 6.0.8
redis_1 | 1:M 23 Sep 2020 21:40:27.819 * RDB age 27 seconds
redis_1 | 1:M 23 Sep 2020 21:40:27.819 * RDB memory usage when created 0.77 Mb
redis_1 | 1:M 23 Sep 2020 21:40:27.819 * DB loaded from disk: 0.000 seconds
redis_1 | 1:M 23 Sep 2020 21:40:27.819 * Ready to accept connections
web_1 | * Serving Flask app "app.py"
web_1 | * Environment: production
web_1 | WARNING: This is a development server. Do not use it in a production deployment.
web_1 | Use a production WSGI server instead.
web_1 | * Debug mode: off
web_1 | * Running on http://0.0.0.0:5000/ (Press CTRL+C to quit)
Need to properly allow traffic through that port by:
Creating a firewall rule with a tag
Including that tag in the VM's Network settings
Link here: Network Tags
I am trying to remote debug server side swift from macOS.
lldb-server run on Ubuntu 16.04 on Docker on macOS.
I am using swift-4.1-RELEASE binaries.
root#031ab2443e1a:/var/vapor# lldb-server version
lldb version 5.0.0 (git#github.com:apple/swift-lldb.git revision 76dfa56ed35eaa392f7e51088c08f08f1150d142)
Swift-4.1 (revision f01501c324876fc07820dc28923d7088fb7af847)
clang revision cd84be6c4294f9ec302c20c63a601cbaeaa6a017
llvm revision cf364153438b3ac07a4a7d721159936e439ba2e7
I am also using swift-4.1-RELEASE snapshot on macOS.
[omochi#omochi-iMac-PC43 ~]$ export TOOLCHAINS=org.swift.4120180329a
[omochi#omochi-iMac-PC43 ~]$ lldb -version
lldb-360.0.0 (buildbot 2018-03-29)
Swift-4.1 (revision f01501c324876fc07820dc28923d7088fb7af847)
clang revision cd84be6c4294f9ec302c20c63a601cbaeaa6a017
llvm revision cf364153438b3ac07a4a7d721159936e439ba2e7
I could connect them.
In server.
root#031ab2443e1a:/var/vapor# lldb-server platform --listen "*:31166" --server
Connection established.
In mac.
[omochi#omochi-iMac-PC43 ~]$ lldb
(lldb) platform select remote-linux
Platform: remote-linux
Connected: no
(lldb) platform connect connect://127.0.0.1:31166
Platform: remote-linux
Triple: x86_64-*-linux-gnu
OS Version: 4.9.93 (4.9.93-linuxkit-aufs)
Kernel: #1 SMP Wed Jun 6 16:55:56 UTC 2018
Hostname: 031ab2443e1a
Connected: yes
WorkingDir: /var/vapor
(lldb) platform process list
6 matching processes were found on "remote-linux"
PID PARENT USER TRIPLE NAME
====== ====== ========== ======================== ============================
1 0 (null) x86_64-*-linux dash
291 1 x86_64-*-linux vapor
423 0 x86_64-*-linux bash
572 291 x86_64-*-linux Run
587 0 x86_64-*-linux bash
676 423 x86_64-*-linux lldb-server
But, attach fails.
(lldb) attach 572
error: attach failed: Failed to connect port
I tested lldb in ubuntu to connect lldb-server in itself.
Then attach is succeeded.
So I think lldb-server run correctly to attach process.
Why attach from macOS is failed?
How to solve this.
I found answer. lldb-server and lldb use other ports to debug. it can be specified by --min-gdbserver-port and --max-gdbserver-port options of lldb-server. And I expose these ports I specified via docker function. I finally success to connect.
Just to elaborate on omochimetaru answer, you can specify the ports used by LLDB-server as such:
lldb-server platform --listen "*:31166" --server --min-gdbserver-port 31200 --max-gdbserver-port 31300
And of course you need to expose those ports in your Dockerfile:
EXPOSE 31166
EXPOSE 31200-31300
And also when you run the container:
docker run --privileged --name vapor-server -p 8080:8080 -p 31166:31166 -p 31200-31300:31200-31300 vapor-image
Please note you need to run the docker as privileged (--privileged option), otherwise attaching the debugger will fail with an Operation not Permitted error.
Unable to connect to mongodb cloud using mongoshell from Docker.
Working on Opensuse 42.3 linux platform. IP_FORWARD has been enabled, firewall has been disabled.
./mongodbshell/bin/mongo "mongodb+srv://cluster0-ry2xn.mongodb.net/test" --username
However it works fine from outside docker. Given below is my docker environment info.
$ sudo docker info
Containers: 17
Running: 1
Paused: 0
Stopped: 16
Images: 21
Server Version: 17.04.0-ce
Storage Driver: overlay
Backing Filesystem: xfs
Supports d_type: true
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
Volume: local
Network: bridge host macvlan null overlay
Swarm: active
NodeID: kh7m6ppbeg3ktkk3tueqoiyen
Is Manager: true
ClusterID: izl7e06qo269ccagfa0eknz16
Managers: 1
Nodes: 1
Orchestration:
Task History Retention Limit: 5
Raft:
Snapshot Interval: 10000
Number of Old Snapshots to Retain: 0
Heartbeat Tick: 1
Election Tick: 3
Dispatcher:
Heartbeat Period: 5 seconds
CA Configuration:
Expiry Duration: 3 months
Node Address: 192.168.2.14
Manager Addresses:
192.168.2.14:2377
Runtimes: oci runc
Default Runtime: runc
Init Binary:
containerd version: (expected: 422e31ce907fd9c3833a38d7b8fdd023e5a76e73)
runc version: N/A (expected: 9c2d8d184e5da67c95d601382adf14862e4f2228)
init version: N/A (expected: 949e6facb77383876aeff8a6944dde66b3089574)
Security Options:
apparmor
Kernel Version: 4.4.104-39-default
Operating System: openSUSE Leap 42.3
OSType: linux
Architecture: x86_64
CPUs: 4
Total Memory: 15.45GiB
Name: linux-xleg.suse
ID: SFKG:TIYZ:65WL:TKCG:ZOSW:7ZJI:CW6E:2HJJ:UV7A:ZVXM:V2IN:JZU4
Docker Root Dir: /home/maggi/docker-data
Debug Mode (client): false
Debug Mode (server): false
Username: magnusmel
Registry: https://index.docker.io/v1/
Experimental: false
Insecure Registries:
127.0.0.0/8
Live Restore Enabled: false
WARNING: No swap limit support
WARNING: No kernel memory limit support
Docker oS based on kali linux -
cat /etc/os-release
PRETTY_NAME="Kali GNU/Linux Rolling"
NAME="Kali GNU/Linux"
ID=kali
VERSION="2016.2"
VERSION_ID="2016.2"
ID_LIKE=debian
ANSI_COLOR="1;31"
HOME_URL="http://www.kali.org/"
SUPPORT_URL="http://forums.kali.org/"
BUG_REPORT_URL="http://bugs.kali.org/"
MongodB Client Info is given below
/opt/mongodbshell/bin/mongo --version
MongoDB shell version v3.6.2
git version: 489d177dbd0f0420a8ca04d39fd78d0a2c539420
allocator: tcmalloc
modules: none
build environment:
distarch: x86_64
target_arch: x86_64
ERROR OUTPUT:
> connecting to: mongodb+srv://cluster0-ry2xn.mongodb.net/test
> 2018-01-30T18:54:38.451+0000 I NETWORK [thread1] Starting new replica
> set monitor for
> Cluster0-shard-0/cluster0-shard-00-00-ry2xn.mongodb.net.:27017,cluster0-shard-00-02-ry2xn.mongodb.net.:27017,cluster0-shard-00-01-ry2xn.mongodb.net.:27017
> 2018-01-30T18:54:39.679+0000 W NETWORK [thread1] Unable to reach
> primary for set Cluster0-shard-0 2018-01-30T18:54:39.679+0000 I
> NETWORK [thread1] Cannot reach any nodes for set Cluster0-shard-0.
> Please check network connectivity and the status of the set. This has
> happened for 1 checks in a row. 2018-01-30T18:54:41.879+0000 W NETWORK
> [thread1] Unable to reach primary for set Cluster0-shard-0
> 2018-01-30T18:54:41.879+0000 I NETWORK [thread1] Cannot reach any
> nodes for set Cluster0-shard-0. Please check network connectivity and
> the status of the set. This has happened for 2 checks in a row.
Is this related to not setting up, SSL/TLS based auth ? Any help will be appreciated very much.
IP_FORWARD is not enough, you need masquerade (or NAT) between those different networks. It is possible also do with static routing, if there is one common gateway between networks.
Kali linux is not a supported distro by mongo.
So one needs, to verify if /usr/bin/mongo --version does not return with openssl mentioned in the output.
Then, in such a case uninstall all the existing mongodb tools & server & client.
And then reinstall with a mongo client built for debian 7/8 platform depending on the Kali linux distro Version being used. (in my case debian version 8 )
That solves the issue for running a mongo client with ssl on docker:
apt-key adv --keyserver hkp://keyserver.ubuntu.com:80 --recv 2930ADAE8CAF5059EE73BB4B58712A2291FA4AD5
echo "deb http://repo.mongodb.org/apt/debian jessie/mongodb-org/3.6 main" | tee /etc/apt/sources.list.d/mongodb-org-3.6.list
apt-get update
For full mongodb installation that includes server, do run as given below:
apt-get install -y mongodb-org=3.6.2 mongodb-org-server=3.6.2 mongodb-org-shell=3.6.2 mongodb-org-mongos=3.6.2 mongodb-org-tools=3.6.2
For installing only mongo client & tools specific to a version:
apt-get install -y mongodb-org-shell=3.6.2 mongodb-org-tools=3.6.2
For installing only mongo client & tools default:
apt-get install -y mongodb-org-shell mongodb-org-tools
My mongo output on docker - kali linux image now shows ssl configured:
MongoDB shell version v3.6.2
git version: 489d177dbd0f0420a8ca04d39fd78d0a2c539420
OpenSSL version: OpenSSL 1.0.1t 3 May 2016
allocator: tcmalloc
modules: none
build environment:
distmod: debian81
distarch: x86_64
target_arch: x86_64
The main goal is to run the ServiceBus in a docker container for windows.
Output of docker version:
Client:
Version: 1.13.1
API version: 1.26
Go version: go1.7.5
Git commit: 092cba3
Built: Wed Feb 8 08:47:51 2017
OS/Arch: windows/amd64
Server:
Version: 1.13.1
API version: 1.26 (minimum version 1.24)
Go version: go1.7.5
Git commit: 092cba3
Built: Wed Feb 8 08:47:51 2017
OS/Arch: windows/amd64
Experimental: true
Dockerfile content:
# Is used as sql server local storage for servicebus
FROM microsoft/mssql-server-windows-express
COPY install/ /install
# WebPlatform Installer http://download.microsoft.com/download/C/F/F/CFF3A0B8-99D4-41A2-AE1A-496C08BEB904/WebPlatformInstaller_amd64_en-US.msi
RUN msiexec /i install\WebPlatformInstaller_amd64_en-US.msi /qn
# Install servicebus using webpicmd offline installation https://msdn.microsoft.com/en-us/library/dn441408.aspx#BMK_SBConfig1616
RUN WebpiCmd /Install /Products:ServiceBus_1_1 /AcceptEula /SuppressReboot /xml:c:\install\SBWebPICache\feeds\latest\webproductlist.xml
Steps to reproduce:
1. Build image with parameters:
docker build --no-cache -t servicebus $folder
...
Verifying successful installation...
Microsoft Visual C++ 2012 SP1 Redistributable Package (x64) True
Microsoft Windows Fabric V1 RTM True
Microsoft Windows Fabric V1 CU1 True
Windows Azure Pack: Service Bus 1.1 True
Windows Azure Pack: Update for Service Bus 1.1 - .NET Framework 4.6 Compatibility (KB3086798) True
Install of Products: SUCCESS
Servicebus installed successfully as expected
2. Run container with parameters:
docker run -it --rm --isolation hyperv servicebus powershell
3. Create new servicebus farm:
New-SBFarm -SBFarmDBConnectionString 'data source=.; integrated security=true' -CertificateAutoGenerationKey (ConvertTo-SecureString -string "P#assword" -force -AsPlainText)
Failed with error:
New-SBFarm : The Server service is not started.
Starting service manually:
Start-Service : Service 'Server (LanmanServer)' cannot be started due to the following error: Cannot start service LanmanServer on computer '.'
Found that service depends on ‘srvnet’ that fails to start on Windows 10 (10.0.14393) using hyper-v isolation:
Start-Service : Failed to start service 'srvnet (srvnet)'.
But successfully starts on Windows Server 2016 (10.0.14393) using process isolation. However, even with srvnet service running and File-Services installed it's still not working. Server lanmanserver service can not be started
Question:
Are any possibilities to make lanmanserver working inside windows container? Or any other ways to create servicebus farm?
I need an advice for a trouble with "cf ic create volume" in bluemix for a days. I want to know the cause of the failure, whether bluemix's issue or issues in my setup procedure.
The command and response in the Docker Quickstart Terminal on Windows Server 2012R2:
$ cf ic create volume testvol
Error response from daemon:
{
"incident_id": "1455-1484451778.065-3843854",
"code": "IC5051E",
"description": "The image volume could not be retrieved. Verify that the image ID or name is correct.",
"environment": "prod-dal09",
"rc": "404",
"host_id": "177",
"type": "Infrastructure",
"name": "ImageNotFound"
}
FAILED
Command failed
Incident report on bluemix:
RESOLVED: Issues creating container volumes in US South and United Kingdom regions
Users are experiencing issues creating new file shares within the IBM Bluemix Container Service. Because of this, new volume creation is also affected. The engineering teams are working to restore service.
UPDATE 2017-01-13 22:10 UTC: the issue has been solved.
Updated: Jan 14, 2017 12:05 AM UTC+0000
Starts: Jan 9, 2017 6:59 PM UTC+0000
Ends: Jan 13, 2017 10:10 PM UTC+0000
Category: IBM Containers
Region(s): us-south
eu-gb
ID: 296975
My region is us-south. It looks resolved though my command still failed.
My environment is:
cf version 6.22.2+a95e24c-2016-10-27
IBM-Containers 0.8.964 ic IBM Containers plug-in
docker version Client:
Version: 1.12.5
API version: 1.24
Go version: go1.6.4
Git commit: 7392c3b
Built: Fri Dec 16 06:14:34 2016
OS/Arch: windows/amd64
docker version Server:
Version: 1.12.6
API version: 1.24
Go version: go1.6.4
Git commit: 78d1802
OS:Windows server 2012R2 on VMWare Workstation 12 Pro
You are typing the wrong command to create the volume.
The correct command to create a volume is:
$ cf ic volume create VOLUME_NAME
cf ic create will try to create a new container and it is expecting that volume is the image name, hence the error you are seeing.
You can see complete docs in the link below:
https://console.ng.bluemix.net/docs/containers/container_cli_cfic.html#container_cli_reference_cfic__d1430e3797