I'm trying to deploy a simple yesod web site using stack docker.
My steps:
stack yesod init ... stack exec -- yesod devel works fine.
export DOCKER_HOST=myhost and test docker info runs ok.
add docker: \n enable: true to stack.yaml.
Then, fail
$ stack docker pull
Pulling image from registry: 'fpco/stack-build:lts-3.1'
Pulling repository docker.io/fpco/stack-build
Tag lts-3.1 not found in repository docker.io/fpco/stack-build
Could not pull Docker image:
fpco/stack-build:lts-3.1
There may not be an image on the registry for your resolver's LTS version in stack.yaml.
I'm using
$ stack exec -- ghc --version
The Glorious Glasgow Haskell Compilation System, version 7.10.2
I know
Not every LTS version is guaranteed to have an image existing, and new
LTS images tend to lag behind the LTS snapshot being published on
stackage.org. Be warned: these images are rather large!
My first goal is use stack docker and to know if I do something wrong.
Thank you!
For the moment, use a resolver setting in your stack.yaml that matches one of the available tags, such as resolver: lts-2.22 (see https://hub.docker.com/r/fpco/stack-build/tags/ for a list). I'm working on LTS 3.x images, but have run into some trouble building all the packages in it, and debugging has gone slowly due to how long it takes to build all of Stackage.
Related
I am trying to establish a LDAP connection (<cfldap>) from within a Docker image of Coldfusion 2021. It would be hard to post any relavent code here simply because it would expose our AD tree, however, the same code I am trying to run works just fine from an installed copy of CF2021 on a linux server.
The reason for using a Docker image (vs. install) in this instance, is an attempt to setup a local development (MACOS) environment. So far, everything seems to be working great with the exception of LDAP calls.
Note: I have successfully run a ldapsearch call from a bash shell within the container.
The error I'm getting:
An error has occurred while trying to execute query :Could not resolve
a valid ldap host
The Docker image repo I pulled from:
https://hub.docker.com/r/adobecoldfusion/coldfusion
Update: I've just noticed CF version differences between the server that isn't having the problems:
Linux Version: 2021,0,01,325996 (installed a few weeks ago non-Docker)
Local MACOS: 2021,0,02,328618 (Docker)
Update 2: We've installed a fresh ColdFusion 2021 Docker image on a Linux box directly connected to our network and we are still seeing this issue. This narrows the issue down to Adobe Cold Fusion 2021's interaction with Docker and it's ability to do <CFLDAP>.
Update 3: 10-13-2021 - It would appear the CF team is aware of this, has confirmed the bug and is looking into it.
Update 4: 11-12-2021 - This bug is related to the version of Java running within the Docker image. "Adobe CF support suggested updating to JAVA SE 11.0.13 (LTS) inside the docker container" which has worked when tested. Expect CF to solve the problem in future Docker CF2021 releases.
I'm trying to create a Docker context that will automatically integrate with AWS's ECS.
I'm following this tutorial
The author just does:
docker context create ecs myecs and gets a "pick an integration" prompt, whereas I get an error saying it needs exactly 1 argument.
docker context create" requires exactly 1 argument.
See 'docker context create --help'.
Usage: docker context create [OPTIONS] CONTEXT
Create a context
You need to install the Docker Compose CLI preview
The below curl is from here: Docker docs
curl -L https://raw.githubusercontent.com/docker/compose-cli/main/scripts/install/install_linux.sh | sh
sudo docker context create ecs myecs
It didn't work without sudo for me for some reason.
After the script finished I had some weird errors:
cp: cannot stat '/tmp/tmp.d4QjhW8T6k/docker-compose': No such file or directory and docker context create ecs myecs didn't work at first, but once I tried with sudo it worked fine.
EDIT: . ~/.zshrc (or just close your terminal and open a new one) made it possible for me to run docker context create ecs myecs without sudo.
Author of the blog/tutorial here. It looks like you don't have the pre-requsite installed. In the blog I call out the pre-req in pieces like this.
....In July, Docker released a beta for Docker Desktop that embedded these functionalities and, on September 15th, Docker released an updated experience in their Docker Desktop stable channel....
and then
...For now the only thing you need is Docker Desktop and an AWS account. For this test , I am using Docker Desktop (stable) version 2.5.0.1....
and finally
The core of this integration is built around a new tool dubbed Compose CLI (this is not to be confused with the original docker-compose CLI). This new CLI surfaces to the user as new functionalities in the docker command. While in Docker Desktop all this plumbing is completely hidden and available out of the box, if you are using a Linux machine you can set it up using either a script or a manual install. This new CLI is, essentially, a new version of the docker binary.
Eager to understand more how we could make it more clear / front and center that there were stuff to install and/or minimum software versions you had to use.
Thanks for trying it out!
If you're on Linux and you're running the docker context create ecs myecscontext command from the docs then try enabling experimental features in docker:
Edit /etc/docker/daemon.json
Set contents to
{
"experimental": true
}
Restart docker service sudo systemctl restart docker
Exit your terminal and open a new one so that the changes take effect.
Source1
Source2
I had same issue but after installing Docker Desktop version problem resolved.
Server side version doesn't have such kind of functionality.
I am developing a Django app locally with Visual Studio Code. In preparation for deployment I "dockerized" everything and now I am already able to run this container locally.
Before I try to build my Docker image somewhere else (I have Google Cloud Run in mind), I want to make sure that I still can debug my code.
With the official 'Python in a container' tutorial I am able to set breakpoints and so on when my app runs locally with Docker.
So I think the workflow will look like this:
I develop my app locally and debug it within Visual Studio Code.
For further debugging I can do this locally with Docker as described above.
When everything looks good I push this container to Google Cloud Run or whatever.
Does that sound like a reasonable plan or did I miss something important? In the end, I am looking for an easy convenient way to continuously develop (and debug) a Django app with Visual Studio Code and deploy it with Docker.
I've never used Google Cloud Run or smth, but based on experience with remote servers I can advice following approach. You can use github actions and docker hub. Cover your application or at least critical parts of it with tests which will ensure that everything important works properly. You can set github actions up the way that your tests will be run everytime you push to your github repo. If tests will be passed an image of your application (usually it's name is your_app:latest) will be updated on dockerhub allowing you to build from an image. It's a good practice to have multiple images. For example you could have a stable version, say v.1.0 and a beta version your_app:latest. Thus you will be able to run your stable version on a production server, while beta version can be run on a development server. Do not update stable versions, release new ones and keep existing ones.
An example of how github actions file can look like:
name: your_app_workflow
on: [push]
jobs:
tests:
# run your tests here
push_to_docker_hub:
name: Push Docker image to Docker Hub
runs-on: ubuntu-latest
needs: tests
steps:
- name: Check out the repo
uses: actions/checkout#v2
- name: Push to Docker Hub
uses: docker/build-push-action#v1
with:
username: ${{ secrets.DOCKER_USERNAME }}
password: ${{ secrets.DOCKER_PASSWORD }}
repository: your_repository_on_dockerhub
tag_with_ref: true
Maybe you know following, but I will mention it anyway. Django built in database is SQLite which is not reliable at all, thus if you are going to let others use your product, you MUST think of another database. Current standard in web industry is PostgreSQL. There are Mongo, Redis and others, but PostgreSQL is used the most. Also, Django doesn't serve static and media files in production, so you will have to use proxy server such as Nginx. Nginx can not work with your Django app directly thus you will need an intermediary such as Gunicorn. Again, I don't know about Google Cloud Run but on a typical remote server you would do it this way.
The apt-buildpack is experimental and not yet intended for production use. I guess that's why also no documentation.
Creating container
Successfully created container
Downloading app package...
Downloaded app package (862.7K)
Warning: this buildpack can only be run as a supply buildpack, it can not be run alone
Failed to compile droplet: Failed to compile droplet: exit status 1
Destroying container
Exit status 223
Stopping instance abdfc8d0-699e-4834-9f2d-2b8aec218423
Successfully destroyed container
Can you give me example how to push cf-env sample app and install for example rtorrent and/or openvpn. Is it possible to install gnome for testing purposes?
As far as usage goes it's pretty simple, you just need to include an apt.yml in the root directory of your app. That should contain among other things, the list of packages to install.
Ex:
---
packages:
- ascii
- libxml
- https://example.com/exciting.deb
The buildpack supports installing package names, deb files, custom APT repositories, and even PPAs.
Please see the README for further instructions.
This message:
Warning: this buildpack can only be run as a supply buildpack, it can not be run alone
Is telling you that the Apt buildpack only functions to supply binaries. It doesn't actually know how to run your app or any application. For more on the supply script, check out the docs here.
The trick to making it work is that you need to use multi buildpack support. Instructions for doing that can be found here. This should work with most apps, but there's a simple example here.
Once your app stages & starts, you can confirm that your packages were installed by running cf ssh apt-test -t -c "/tmp/lifecycle/launcher /home/vcap/app bash ''". Anything that was installed should be on the path, but if you want to see where things are installed it'll be under the /home/vcap/deps/<buildpack-number>/.
That should be about it. Hope that helps!
I'm working on a project that I haven't touched in about 4 months. Before everything on the deploy was working fine, but now I'm getting an error when trying to deploy an update.
Failed to pull Docker image amazon/aws-eb-python:3.4.2-onbuild-3.5.1: Pulling repository amazon/aws-eb-python time="2016-01-17T01:40:45Z" level="fatal" msg="Could not reach any registry endpoint" . Check snapshot logs for details. Hook /opt/elasticbeanstalk/hooks/appdeploy/pre/03build.sh failed. For more detail, check /var/log/eb-activity.log using console or EB CLI.
In the eb-activity log, it further states [CMD-AppDeploy/AppDeployStage0/AppDeployPreHook/03build.sh] : Activity execution failed, because: Pulling repository amazon/aws-eb-python before repeating what was shown in the UI.
The original was using a Preconfigured Docker 64bit Debian jessie v1.3.1 running Python 3.4. I've tried upgrading to the latest, which is version 2.0.6, but it never completes (don't need to get into specifics of that error, separate issue and I'd like to stay on 1.3.1 if possible). I've also tried upgrading to the latest 1.x but it has the same result of upgrading to 2.0.6.
Any ideas, or anything else I should be looking for clues?
Docker Hub has deprecated pulls from Docker clients on 1.5 and earlier. Make sure that your docker client version is at least above 1.5. See https://blog.docker.com/2015/10/docker-hub-deprecation-1-5/ for more information.