Docker Compose online guides describe the profiles feature that allows to run different containers described in the same configuration file just using different profiles with option --profile : here (in short) and here (in details).
The profiles compose file option (describing for which profiles a service should run) is mentioned in compose file 3.0 format specification without any other version restrictions, so it looks like it should work for all 3.* versions.
But the instances of Docker Compose that I have installed on my Windows workstation and on my dev server under CentOS 7 (both has version 1.27.4, build 40524192) just doesn't have this option in their CLI. The docker-compose --help command shows no --profile option in its output, and it really doesn't work when I try it. Instead, there are --context and --env-file options (that are absent in the online guide), but it looks like both are something different.
Does anyone know what's happened with Docker Compose profiles? Are this feature removed (I was unable to find anything about it)? Or are they available in different mode or something (I know that some options work only for docker stack, not for docker-compose, but the former one doesn't have it too neighter in online descrition nor in --help output)? Or do I do something wrong?
As clcto answered, the version of Docker Compose that I used is just too old: to use profiles, version 1.28.0 or later is required.
For Windows, the usual way to receive Docker Compose is to install Docker Desktop that contains Docker, Docker Compose and more, and the actual version of Docker Desktop still contains Docker Compose 1.27.4. As a workaround, I downloaded corresponding Docker Compose exe file from here and replaced the existing c:\Program Files\Docker\Docker\resources\bin\docker-compose.exe file with it — it was enough.
Related
Having an application with about 30 dependencies, we report about the licenses in the app via the default showLicensePage.
How can we export this list to a CSV format (including transitive dependencies)? I am looking for something like this:
package name,transitive (direct/transitive),license,link
some_package,direct,MIT,https://github.com/someone/some_package
...
The LicenseFinder has support for flutter since version 7.0.0 and supports many output formats including csv. The good thing over e.g. flutter_oss_licenses is that it also provides the license name (not only the license text) and also has many other features (e.g. allowing a set of licenses, CI-support, other languages/package-managers support etc.), it is actively maintained by pivotal and is itself MIT licensed.
For example, one can use the docker version to run it (see README - for more information how to run the tool).
Then you can get a csv report for your flutter project with a command like this:
cd some_flutter_project
docker run -v $PWD:/scan -it licensefinder/license_finder:7.0.1 /bin/bash -lc "cd /scan && PUB_CACHE=~/.pub license_finder report --format=csv -p"
This command will mount the current working directory to the docker container and analyze it. The -p option runs flutter pub get in the docker container to setup the dependency cache that is then analyzed.
Note that the command will print the result to standard out, but you can, for example, pipe it to a file (command from above) > out.csv.
While reproducing steps from an interesting tutorial found online - Hyperledger Fabric 1.4 Tutorial - FabCar Sample Application, I have installed all Hyperledger Fabric binaries via the Curl command:
curl -sSL https://raw.githubusercontent.com/hyperledger/fabric/master/scripts/bootstrap.sh | bash -s
From the Command Prompt window one can see that, the scripts are run correctly leading to the pull of hyperledger-docker images.
However, while launching the network from Visual Studio Code through the execution of
./startFabric.sh javascript from the fabcar sub-directory, one ends up with Fabric Images issues, which seems paradoxical.
A similar issue has been encountered, while attempting to bring up the network via the command
./network.sh up
from the test-network sub-directory too.
Thus, any relevant feedback would indeed be appreciated, given an absence of rationale to justify this matter.
[EDIT]
As a matter of fact, a synchronization issue might have caused the previously reported issue, since fabric-samples v.1.4.9 is not found from Curl command documented online. Thus the script automatically installs the latest Fabric binaries 2.x.
To rule out this issue, I have re-executed the Curl command by specifying the version 1.4.4 instead.
Therefore I can confirm, that the test-network sub-directory is not part of the Fabric binaries pertaining to the version 1.4x.
Furthermore, before the installation of this binaries, I had removed all containers, and related images, yielding to:
Back to the fabcar sub-directory, running:
./startFabric.sh javascript has still led to the following network issue :
What strikes me the most is:
firstly, that configtxlator can be found on my C:\Users\...\Documents\test4\fabric-samples\bin as opposed to the path highlighted on the command window.
secondly, I do not see the matter of version's incompatibility by scrutinizing byfn.sh:
Eventually, the manual amendment of IMAGETAG has not improved the situation.
Best
You seem to have the different version.
In hyperledger/fabric-samples, the test-network does not exist in version 1.4. In other words, you are running the code for the master version of fabric-samples (currently the version 2.x version). Since you're running the 1.4 tutorial, run the commands based on the 1.4 documentation and code.
fabric/docs/release-1.4
fabric/samples/release-1.4
[NOTE] It is also very likely that the different version binary has been installed. In the fabric document, the version can be specified and downloaded, so to download the binary of the corresponding version, you need to execute the command including the input parameter (version) below.
curl -sSL https://raw.githubusercontent.com/hyperledger/fabric/master/scripts/bootstrap.sh | bash -s - 1.4.9 1.4.9 0.4.21
[EDIT - 1]
Prior to the explanation, in 1.4.x, first-network/byfn.sh exists, not test-network/network.sh. Change the branch of your fabric-samples to release-1.4.
Do not run 2.x code while doing the 1.4 tutorial.
./byfn.sh basically executes the image tag as latest. That is, if you have pulled the 2.x version of the image, even if you proceed to 1.4.x, it will run as 2.x.
cd fabric-samples
git checkout release-1.4
There are two ways.
tag the latest with 1.4.x image
Untag all hyperledger latest image tags, and tag 1.4.x images as latest.
(In fact, the easiest way is to delete both the 2.x and 1.4.x images and execute the command again.)
Or edit in byfn.sh
There is a part to set IMAGE_TAG in byfn.sh.
byfn.sh
# default image tag
# IMAGETAG="latest"
IMAGETAG="1.4.9"
Make sure the value of that part matches your 1.4.x version
[EDIT - 2]
For binary I don't know where and how you built it. However, you can easily build it on the fabric github.
make binaries
cd $GOPATH/src/github.com/hyperledger
git clone http://github.com/hyperledger/fabric
cd fabric
git checkout release-1.4
make native
Makefile
native - ensures all native binaries are available
configtxgen - builds a native configtxgen binary
configtxlator - builds a native configtxlator binary
cryptogen - builds a native cryptogen binary
idemixgen - builds a native idemixgen binary
peer - builds a native fabric peer binary
orderer - builds a native fabric orderer binary
Path setting
mv $GOPATH/src/github.com/hyperledger/fabric/.build/bin/* <your_bin_path>
# in my case
# mv $GOPATH/src/github.com/hyperledger/fabric/.build/bin/* usr/local/bin
or
export PATH=$PATH:$GOPATH/src/github.com/hyperledger/fabric/.build/bin
I want to install and set up TYPO3 on my local machine. What's the best practice and fastest way to do so?
For running TYPO3 on a local machine you need a web server running on your machine.
This can be done in different ways:
Native Web Server, PHP and database on a Linux based machine
Virtual Machine (VirtualBox, VMWare, Parallels, etc.)
Vagrant
Docker
Currently the fastest way to a "non power user" in my opinion is ddev.
ddev is a user-friendly possibility to run a perfect environment for TYPO3 on a docker base. It runs on Linux, Mac and Windows (minimum version 10, hyper-v recommended) and it brings all technologies you need for best experience.
Install Docker and ddev, see https://ddev.readthedocs.io/en/stable/
Create a folder for your installation, e.g. ~/Websites/my-website/ or C:\Websites\my-website\ and go into it.
Run ddev config and set these three options in the dialog:
Project name (default is your folder name): Whatever you like
Docroot location: public and say yes for creating
Project type: typo3
Run ddev start to start the Docker containers and add your root password to set the hosts entry (for accessing it via local domain)
Run ddev composer create typo3/cms-base-distribution ^9 and say yes for overwriting
Run ddev config again and just hit enter for every dialog to create a file which provides the DB credentials for your TYPO3 installation
Run ddev exec vendor/bin/typo3cms install:setup --no-interaction --admin-user-name=admin --admin-password=password --site-setup-type=site
That's all, you have a running TYPO3 instance on your local machine.
You can access it by using <project-name>.ddev.site in your browser, in our example it should be http://my-website.ddev.site. To get into the TYPO3 backend you only need to put the credentials admin:password on http://my-website.ddev.site/typo3.
For troubleshooting go to:
https://ddev.readthedocs.io/en/stable/users/troubleshooting/
https://docs.typo3.org/typo3cms/InstallationGuide/Troubleshooting/Index.html
https://docs.typo3.org/typo3cms/ContributionWorkflowGuide/Appendix/SettingUpTypo3Ddev.html
I need to run java command from python flask application which is deployed using cf. How can we make java runtime available to this python flask app.
I tried using multi-buildpack, but java_buildpack expects some jar or war to be executed while deploying the application.
Any approach that would make java available to python flask app?
The last buildpack in the buildpack chain is responsible for determining a command to start your application which is why the Java buildpack expects a JAR/WAR to execute.
The Java buildpack, as of writing this, does not ship a supply script so it can only be run as the last buildpack when using multi buildpack support. It looks like that at some point in the future the Java buildpack will provide a supply script, but this is still being worked out here.
For now, what you can do is use the apt-buildpack and install a JRE/JDK that way.
To do this, add a file called apt.yml to the root of your project folder. In that file, put the following:
---
packages:
- openjdk-8-jre
repos:
- deb http://ppa.launchpad.net/openjdk-r/ppa/ubuntu trusty main
keys:
- https://keyserver.ubuntu.com/pks/lookup?op=get&search=0xEB9B1D8886F44E2A
This will tell the apt buildpack to add a PPA for Ubuntu Trusty where we can get the latest openjdk8. This gets installed under /home/vcap/deps/0, which puts the java executable at /home/vcap/deps/0/lib/jvm/java-8-openjdk-amd64/bin/java.
Note: The java binary is unfortunately not on the path because of the way Ubuntu uses update-alternatives and we can't use that tool to put it on the path in the CF app container because we don't have root access.
After setting that up, you'd follow the normal instructions for using multiple buildpacks.
$ cf push YOUR-APP --no-start -b binary_buildpack
$ cf v3-push YOUR-APP -b https://github.com/cloudfoundry/apt-buildpack#v0.1.1 -b python_buildpack
Note: The process to push using multiple buildpacks will likely change in the future and v3-push, which is currently experimental, will go away.
Note: The example above hard codes version v0.1.1 of the apt buildpack. You should use the latest stable release, which you can find here. Using the master branch is not recommended.
One way to achieve your goal to combine Java and Python would be with context-based routing. I have an example to combines Python and Node.js, but the approach is the same.
Basically, you have a second app serving one or more paths of a domain / URI.
I'm trying to imagine a workflow that could be applied on a scientific work environment. My work involves doing some scientific coding, basically with Python, pandas, numpy and friends. Sometimes I have to use some modules that are not common standards in the scientific community and sometimes I have to integrate some compiled code in my chain of simulations. The code I run is most of the time parallelised with IPython notebook.
What do I find interesting about docker?
The fact that I could create a docker containing my code and its working environment. I can then send the docker to my colleges, without asking them to change their work environment, e.g., install an outdated version of a module so that they can run my code.
A rough draft of the workflow I have in mind goes something as follows:
Develop locally until I have a version I want to share with somebody.
Build a docker, possibly with a hook from a git repo.
Share the docker.
Can somebody give me some pointers of what I should take into account to develop further this workflow? A point that intrigues me: code running on a docker can lunch parallel process on the several cores of the machine? e.g., an IPython notebook connected to a cluster.
Docker can launch multiple process/thread on multiple core. Multiple processes may need the use of a supervisor (see : https://docs.docker.com/articles/using_supervisord/ )
You should probably build an image that contain the things you always use and use it as a base for all your project. (Would save you the pain of writing a complete Dockerfile each time)
Why not develop directly in a container and use the commit command to save your progress on a local docker registry? Then share the final image to your colleague.
How to make a local registry : https://blog.codecentric.de/en/2014/02/docker-registry-run-private-docker-image-repository/
Even though you'll have a full container, I think a package manager like conda can still be a solid part of the base image for your workflow.
FROM ubuntu:14.04
RUN apt-get update && apt-get install curl -y
# Install miniconda
RUN curl -LO http://repo.continuum.io/miniconda/Miniconda-latest-Linux-x86_64.sh
RUN bash Miniconda-latest-Linux-x86_64.sh -p /miniconda -b
RUN rm Miniconda-latest-Linux-x86_64.sh
ENV PATH=/miniconda/bin:${PATH}
RUN conda update -y conda
* from nice example showing docker + miniconda + flask
Wrt doing source activate <env> in the Dockerfile you need to:
RUN /bin/bash -c "source activate <env> && <do something in the env>"