化率高的網站著陸頁是指用戶在搜索相差產品信息關鍵詞時，進到你的網站并且發起咨詢，那么怎樣的著陸頁能夠吸引用戶呢？下面就讓珠海建站杰作科技小編帶大家來了解一下。

1、導航清晰簡單 導航一定要清晰簡單，如果客戶來到網站，卻因為導航復雜而不能快速找到需要的信息或產品，這必然會流失很大一部分潛在客戶。另外網站除了在視覺上吸引客戶外，還需要保證網站的穩定性、功能性和易用性。

2、突出產品的價值 大多數用戶訪問網站是帶著需求的，希望網站能幫助他們解決一定的問題，這就需要網站突出產品或服務能解決哪些問題，用戶購買后有些什么好處，這樣的信息才能抓住用戶眼球。也許你會問，如何知道網站的信息是否滿足客戶的需求，最簡單的方法是做在線調查。

3、網頁設計大氣美觀 網頁大氣美觀的網站能提升企業的形象，顯得更專業，給用戶一種“高大上”感覺。這個需要UI設計師根據企業的情況用心設計，打造出既符合企業氣質又能提升企業形象的網頁效果。

4、分享用戶評價 產品好不好，除了本身質量之外，還要看產品的口碑好不好。網站上的用戶評價是體現口碑最直接的一種方式，如果網站分享出客戶的綜合評價或評分，一方面能幫助新客戶直觀的了解產品在別的客戶那里的使用情況，另一方面大大促進產品銷售機會。 5、持續改進 為了持續提升用戶體驗，還需要不斷改進完善網站設計，嘗試新的方法和技術，減少客戶流失，提升轉化率。

了解更多網絡營銷請關注珠海網站建設-杰作科技：

www.jiezuo.org

www.jiezuo.net

www.jzuo.cn

ww.zhjiezuo.com

珠海網站建設.com

原文鏈接：http://www.jiezuo.net/yingxiaodongtai/857.html

使是最小的側項目也值得它的CI/CD管道

前言

使用當今的工具，建立一個簡單的CI/CD管道并不困難。即使是做一個小項目，這樣做也是學習很多東西的好方法。Docker、GitLab和Portainer是用于此設置的一些很棒的組件。

一個Demo小項目

這里我們以https://sophia.events/為案例，我們保證頁面的event為最新的。頁面的events在這里[1]

免責聲明:這是一個簡單的項目，但是項目的復雜性在這里并不重要。我們將詳細介紹的CI/CD管道的組件可以以幾乎相同的方式用于更復雜的項目。不過，它們非常適合微服務。

廢話不說，直接上代碼

{
"events": [
{
"title": "All Day DevOps 2018",
"desc": "We're back with 100, 30-minute practitioner-led sessions and live Q&A on Slack. Our 5 tracks include CI/CD, Cloud-Native Infrastructure, DevSecOps, Cultural Transformations, and Site Reliability Engineering. 24 hours. 112 speakers. Free online.",
"date": "17 octobre 2018, online event",
"ts": "20181017T000000",
"link": "https://www.alldaydevops.com/",
"sponsors": [{"name": "all-day-devops"}]
},
{
"title": "Création d'une Blockchain d'entreprise (lab) & introduction aux smart contracts",
"desc": "Venez avec votre laptop ! Nous vous proposons de nous rejoindre pour réaliser la création d'un premier prototype d'une Blockchain d'entreprise (Lab) et avoir une introduction aux smart contracts.",
"ts": "20181004T181500",
"date": "4 octobre à 18h15 au CEEI",
"link": "https://www.meetup.com/fr-FR/IBM-Cloud-Cote-d-Azur-Meetup/events/254472667/",
"sponsors": [{"name": "ibm"}]
},
…
]
}

將mustache[2]模板應用于此文件，以生成最終的web頁面。

基于Docker的多層構建

生成web 頁面之后，將它們復制到nginx image中——部署在目標機器上的image。

然后構建完成了兩個部分，由于多階段構建:

· 資產的生成

· 創建包含資產的最終映像

這是Dockerfile用于構建:

# Generate the assets
FROM node:8.12.0-alpine AS build
COPY . /build
WORKDIR /build
RUN npm i
RUN node clean.js
RUN ./node_modules/mustache/bin/mustache events.json index.mustache > index.html# Build the final image used to serve 
them 
FROM nginx:1.14.0
COPY --from=build /build/*.html /usr/share/nginx/html/
COPY events.json /usr/share/nginx/html/
COPY css /usr/share/nginx/html/css
COPY js /usr/share/nginx/html/js
COPY img /usr/share/nginx/html/img

本地測試

測試目的：只需要clone repo 然后在運行test.sh。test.sh 會創建一個image然后運行。

$ git clone :lucj/sophia.events.git$ cd 
sophia.events$ ./test.sh
Sending build context to Docker daemon 2.588MB
Step 1/12 : FROM node:8.12.0-alpine AS build 
---> df48b68da02a
Step 2/12 : COPY . /build 
---> f4005274aadf
Step 3/12 : WORKDIR /build 
---> Running in 5222c3b6cf12Removing intermediate container 5222c3b6cf12 
---> 81947306e4af
Step 4/12 : RUN npm i 
---> Running in de4e6182036bnpm notice created a lockfile as package-lock.json. You should commit this file.npm WARN www@1.0.0 No repository field.added 2 packages from 3 contributors and audited 2 packages in 1.675sfound 0 vulnerabilitiesRemoving intermediate container de4e6182036b ---> d0eb4627e01f
Step 5/12 : RUN node clean.js 
---> Running in f4d3c4745901Removing intermediate container f4d3c4745901 
---> 602987ce7162
Step 6/12 : RUN ./node_modules/mustache/bin/mustache events.json index.mustache > index.html 
---> Running in 05b5ebd73b89Removing intermediate container 05b5ebd73b89 
---> d982ff9cc61c
Step 7/12 : FROM nginx:1.14.0 
---> 86898218889a
Step 8/12 : COPY --from=build /build/*.html /usr/share/nginx/html/ 
---> Using cache 
---> e0c25127223f
Step 9/12 : COPY events.json /usr/share/nginx/html/ 
---> Using cache 
---> 64e8a1c5e79d
Step 10/12 : COPY css /usr/share/nginx/html/css 
---> Using cache 
---> e524c31b64c2
Step 11/12 : COPY js /usr/share/nginx/html/js 
---> Using cache 
---> 1ef9dece9bb4
Step 12/12 : COPY img /usr/share/nginx/html/img 
---> e50bf7836d2fSuccessfully built e50bf7836d2fSuccessfully tagged registry.gitlab.com/lucj/sophia.events:latest=> web site available on http://localhost:32768

在輸出的信息下面有一個網址 http://localhost:32768

我們打開網址:

環境

在swarm中運行docker

在這里我們用swarm來管理docker。而不是用K8s，swarm稍微簡單些， 也便于大家通過這篇文章來自己實現CI/CD。

讓應用程序運行在docker中

docker compose 如下

version: "3.7"
services: 
 www: 
 image: registry.gitlab.com/lucj/sophia.events 
 networks: 
 - proxy 
 deploy: 
 mode: replicated 
 replicas: 2 
 update_config: 
 parallelism: 1 
 delay: 10s 
 restart_policy: 
 condition: on-failurenetworks: 
 proxy: 
 external: true

簡單說明:

· image被放在了gitlab.com私有倉庫中

· 服務處于具有兩個副本的復制模式，這意味著服務的兩個任務/容器同時運行。VIP(虛擬IP地址)通過集群與服務相關聯，因此每個針對服務的請求都在兩個副本之間實現負載平衡。

· 每次更新服務(部署web站點的新版本)時，更新一個副本，10秒后更新第二個副本。這確保在更新過程中web站點仍然可用。我們也可以使用回滾策略，但是現在還不需要。

· 該服務附加到外部代理網絡，因此TLS終端(運行于部署在集群上的另一個服務中，但不在此項目中)可以向www服務發送請求。

我們通過如下命令運行docker服務:

docker stack deploy -c sophia.yml sophia_events

Docker管理平臺portainer.io

Portainer平臺有一個很棒的web UI界面，它允許用戶非常容易地管理Docker主機和Docker集群。下面是Portainer界面的截圖，它列出了集群中可用的應用。

我們看到有三個實例

· portainer自己

· Sophia_events

· TLS

下面列出位于Sophia_events中的www服務的詳細信息，我們可以看到服務webhook已被激活。自從Portainer 1.19.2(到目前為止的最后一個版本)以來，這個特性就可用了，它允許我們定義一個HTTP Post端點，可以調用它來觸發服務的更新。稍后我們將看到，GitLab運行器負責調用這個webhook。

注意:從屏幕截圖中可以看到，我從localhost:8888訪問Portainer UI。由于我不想將Portainer實例暴露給外部世界，所以通過ssh隧道進行訪問，使用以下命令打開ssh隧道:

ssh -i ~/.docker/machine/machines/labs/id_rsa -NL 8888:localhost:9000 $USER@$HOST

然后，所有針對端口8888上的本地機器的請求都通過ssh發送到虛擬機上的端口9000。9000是Portainer在VM上運行的端口，但是這個端口不對外開放，所以是相對安全的。

注意:在上面的命令中，用于連接VM的ssh密鑰是Docker機器在創建VM期間生成的密鑰。

Gitlab runner

GitLab runner 是一個負責執行. GitLab –ci.yml 文件的驅動 ，當代碼被push到主分支的時候，會自動執行預先寫好的腳本，從而實現自動化。對于這個項目，我們將自己的GitLab runner定義為VM上的docker服務。

下面是配置腳本:

docker run — rm -t -i \
-v $CONFIG_FOLDER:/etc/gitlab-runner \
gitlab/gitlab-runner register \
--non-interactive \
--executor "docker" \
--docker-image docker:stable \
--url "" \
--registration-token "$PROJECT_TOKEN" \
--description "Exoscale Docker Runner" \
--tag-list "docker" \
--run-untagged \
--locked="false" \
--docker-privileged

可以使用PROJECT_TOKEN在gitlab上注冊額外的runners

注冊后，我們直接start

CONFIG_FOLDER=/tmp/gitlab-runner-configdocker run -d \ 
--name gitlab-runner \ 
--restart always \ 
-v $CONFIG_FOLDER:/etc/gitlab-runner \ 
-v /var/run/docker.sock:/var/run/docker.sock \ 
gitlab/gitlab-runner:latest

一旦start成功，我們就會在gitlab上看到項目的信息:

當研發把代碼提交到gitlab上，runners會一次執行:測試、構建、部署等在.gitlab-ci.yml里面定義好的操作。

· 測試階段運行一些預檢查以確保events. json文件格式正確并且images完整 。

· 構建階段構建image并將其推送到GitLab registry 。

· deploy階段通過發送到Portainer的webhook觸發服務的更新。WWW_WEBHOOK變量在GitLab.com項目頁面的CI/CD設置中定義。

注:

這個runners在swarm的容器中運行。我們可以使用一個共享的runner——他們可以在托管的主機上共享資源——但是,runner需要訪問Portainer endpoint (發送webhook),因為我不希望Portainer被玩不訪問。

此外，因為運行器在容器中運行，所以它將webhook發送到Docker0橋接網絡的IP地址，以便通過它在主機上公開的端口9000與Portainer聯系。因此，webhook的格式如下:http://172.17.0.1:9000/api[…]a7-4af2-a95b-b748d92f1b3b

部署過程回顧

網站新版本的更新工作流程如下:

1. 開發人員將一些更改推給GitLab。這些更改基本上涉及事件中的一個或多個新事件。json文件加上一些額外的贊助商的標志。

2. GitLab運行器執行. GitLab -ci.yml中定義的操作。

3. GitLab運行器調用Portainer中定義的webhook。

4. 在webhook接收端，Portainer部署了www服務的新版本。它這樣做，調用Docker Swarm API。Portainer可以作為套接字/var/run/ dockerr訪問API。襪子啟動時是綁定安裝的

5. 然后用戶就可以在web上看到最新的信息了。

小案例

修改一些配置，然后push到gitlab。

$ git commit -m 'Fix image'$ git push origin master

下面的截圖顯示了GitLab.com項目頁面中的提交觸發的信息

在Portainer端，接收webhook并執行服務更新。我們無法在這里清楚地看到它，但是已經更新了一個副本，使web站點可以通過第二個副本訪問。然后，幾秒鐘后，第二個副本被更新。

總結

即使對于這個小項目，設置一個CI/CD管道也是一個很好的練習，尤其是要更加熟悉GitLab。這是一個優秀的產品。這也是使用期待已久的Portainer(1.19.2)最新版本的webhook特性的好機會。另外，對于像這樣的一個小項目，使用Docker Swarm是很簡單的——它很酷，而且很容易使用!

[1]:https://gitlab.com/lucj/sophia.events

[2]:https://gitlab.com/lucj/sophia.events/blob/master/index.mustache